Omnibox - HQP - Frequency Scoring Bug Fix

Omnibox - HQP - Frequency Scoring Bug Fix

The previous fix to detecting page transition types was wrong, but close
enough to correct that it seemed right when I tested it.  I realized it was
wrong when reviewing some other history-processing code today.

(The only places where it was wrong were places that had the same bits set
or more as PAGE_TRANSITION_TYPED: i.e., PAGE_TRANSITION_AUTO_SUBFRAME,
PAGE_TRANSITION_GENERATED, PAGE_TRANSITION_FORM_SUBMIT, and
PAGE_TRANSITION_KEYWORD.  None of these other page transition types
typically make it into HQP in-memory index, which is I why I didn't notice
the effect of my incorrect fix.)

BUG=369989
Committed: https://crrev.com/38a35336354fa51f45dd8029ec0085cf2d396835
Cr-Commit-Position: refs/heads/master@{#322256}

[Mark P, 2015-03-24 18:36:02]

Peter, please take a look, thanks,

--mark

[Mark P, 2015-03-25 21:38:26]

mpearson@chromium.org changed reviewers:
+ pkasting@chromium.org

[Mark P, 2015-03-25 21:38:42]

Peter, please take a look, thanks.

--mark

[Peter Kasting, 2015-03-25 21:42:27]

LGTM, I feel dumb for forgetting that the bottom bits of this are basically an
enum instead of a bitmask.

[Mark P, 2015-03-25 21:47:35]

The CQ bit was checked by mpearson@chromium.org

[commit-bot: I haz the power, 2015-03-25 21:48:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1030913002/1

[Mark P, 2015-03-25 21:55:09]

On 2015/03/25 21:42:27, Peter Kasting wrote:
> LGTM, I feel dumb for forgetting that the bottom bits of this are basically an
> enum instead of a bitmask.

I wonder if other people made the same mistake...

[went to use code search]

Found only one bad example.  Filed a bug.

--mark

[commit-bot: I haz the power, 2015-03-25 23:04:33]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-03-25 23:05:32]

Patchset 1 (id:??) landed as
https://crrev.com/38a35336354fa51f45dd8029ec0085cf2d396835
Cr-Commit-Position: refs/heads/master@{#322256}