Wrong search terms are highlighted on Google

RESOLVED FIXED

Status

()

Firefox
Address Bar
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: jaws, Assigned: dao)

Tracking

35 Branch
Points:
1
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

STR:
Set Google as the default search engine
In the address bar, type "test 123" and hit Enter
Wait for the Google search results page to load
Look at the address bar and notice that `test+123` are highlighted
Change the query to "test 345" and hit Enter
Wait for the new search results to load
Look at the address bar

Expected:
`test+345` are highlighted

Actual:
`test+123` are highlighted

The old `test+123` are still in the URL (the first instance of q=), and the new `test+345` are at the end of the URL (the second instance of q=)

Subsequent searches change the second instance, but always keep the first instance unchanged.
Flags: qe-verify+
Flags: firefox-backlog+
Version: Trunk → 35 Branch
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #0)
> Change the query to "test 345" and hit Enter

The key here is that the query must be changed from within the search results page using the Google search box in content.
(Assignee)

Comment 2

3 years ago
Bummer. Even if we highlighted the right search terms here, users might not see them since they're at the end of the URL and likely cut off, leading to inconsistent behavior. Given this and bug 1069903 I tend to think that bug 1047469 should be backed out...
(Assignee)

Comment 3

3 years ago
[Tracking Requested - why for this release]: because bug 1047469 is riding this train
tracking-firefox35: --- → ?
(Assignee)

Updated

3 years ago
OS: Windows 7 → All
Hardware: x86_64 → All
So, the hilight was a mockup from Boriss, but I'm sure we have another bug with a different UI mockup from phlsa that rather hides completely the search url (until you want to edit it), showing something like "Google - search terms".
That could use the same search service backend as simpel hilight.
I just have to find it...
found it! bug 1048223.
I think it's very hard to fix this bug with the current approach, while that approach would allow us to handle this case.
(Assignee)

Comment 6

3 years ago
Created attachment 8498347 [details] [diff] [review]
backout.diff
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #8498347 - Flags: review?(ttaubert)
(Assignee)

Updated

3 years ago
Iteration: --- → 35.3
Points: --- → 1
Comment on attachment 8498347 [details] [diff] [review]
backout.diff

Review of attachment 8498347 [details] [diff] [review]:
-----------------------------------------------------------------

Too bad this has to be so complicated :/
Attachment #8498347 - Flags: review?(ttaubert) → review+
(Assignee)

Comment 8

3 years ago
https://hg.mozilla.org/integration/fx-team/rev/fdcb83cd2139
tracking-firefox35: ? → ---

Updated

3 years ago
QA Contact: alexandra.lucinet
Closing this bug as bug 1048223 will track the new implementation.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
QA Contact: alexandra.lucinet → andrei.vaida
Since Bug 1047469 was marked as WONTFIX and this implementation will be tracked in Bug 1048223, I believe that at this point there's nothing here for manual QA to poke at. Marking this issue as qe-verify-.

Dao, if you think we should look at this bug differently, please feel free to flip back the flag.
Flags: qe-verify+ → qe-verify-
You need to log in before you can comment on or make changes to this bug.