616331 - 'Search' context menu target does not match menu item text when selection changes

Status: RESOLVED WORKSFORME

(Firefox :: Search, defect)

Description

[Joseph Walton]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101028 Iceweasel/3.5.15 (like Firefox/3.5.15)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101028 Iceweasel/3.5.15 (like Firefox/3.5.15)

Some pages manipulate the selection. If I bring up the context menu before this happens the 'search' item shows the current selection. If this selection then changes while the menu is open, the search will be for the current selection rather than the text on the menu.

Reproducible: Always

Steps to Reproduce:
1. Select a region of text
2. Bring up the context menu and notice that Search is for the text selected
3. Wait for the page to clear its selection
4. Choose the 'Search for' menu item
Actual Results:  
The search results are for the empty string.

Expected Results:  
The search results are for the original text selected when the menu was opened.

Seen on selections on http://www.nytimes.com/ .

Comment 1

[Joseph Walton]

Attachment: Test case demonstrating a page that modifies the selection

Select the text and note that the selection is cleared after a pause. Select again, and bring up the context menu during the pause. After the selection clears, choose 'search' and note that the search is not for the menu item text.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks for filing the bug and the test case! I can see the same with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101201 Firefox/4.0b8pre ID:20101201030318

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Constantly monitoring the selection while the context menu is open (using polling or some kind of selection listener) isn't really practical. Can you maybe give examples of real-world scenarios that this bug affects?

Comment 4

[Joseph Walton]

(In reply to comment #3)
> Can you
> maybe give examples of real-world scenarios that this bug affects?

Yes; here's the example that prompted the report.

View an article on nytimes.com. Choose a short phrase (two words, say) you would like to search for. Double-click and drag to select it by word, then bring up the context menu. Notice that the page clears the selection. Choose the menu item, which implies that it will search for the selected phrase, and notice that the result is instead the search engine front page.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Ah, so "sites that use Tynt". I thought they only messed with the selection on copy...

Comment 7

[blargh]

If you want more real-world examples, stylish scripts that affect text suffer from this problem. I can offer one: 4chan X CSS defaults (http://userstyles.org/styles/48538/4chan-4chan-x-css-defaults) with "Expand filenames" on "Yes". Then go to 4chan, open a thread, and mouse over the filename of an image. Right click and select it, try to search for it, and you will get nothing because the selection has changed after you moved your mouse to the "Search Google for" button.

Comment 8

[blargh]

Dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=525702?

Comment 9

[blargh]

Youtube also suffers from this bug. When you search for a video, there is always a description of each video below its link. Clicking this text always takes you to the video, whether you're in a context menu or not, so it's impossible to use the "Search Google for" command in the youtube search page.

Comment 11

[baffclan]

Cannot reproduce with nightly/Windows7(x64)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160423030220

Comment 12

[Hideo Oshima]

I also cannot reproduce with recent Linux nightly.

Clear selection but Firefox passes selected strings correctly to search engine.
So this bug may be marked worksforme.

Comment 13

[Mark Banner (:standard8)]

I can't reproduce this either on latest nightly. Given the previous two comments, closing as WFM.