2004404 - Right-click to search via extension "ContextSearch web-ext" breaks intermittently due to bug 543435

Status: RESOLVED MOVED

(WebExtensions :: Developer Outreach, defect)

Description

[Fanolian]

Attachment: Icon URL wrongly parsed as {searhTerms}.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0
Build ID: 20251205091840

Steps to reproduce

1. In a new profile, install ContextSearch web-ext latest version (v1.48.4.11), keep settings as default: https://addons.mozilla.org/firefox/addon/contextsearch-web-ext/
2. Go to any page that the extension supports, e.g. https://en.wikipedia.org/wiki/Main_Page. Highlight any words.
3. Hold right-click to trigger the extension's Quick Menu.
4. Right click on Google's search plugin icon.

Expected result

The extension opens Google with the highlighted words as the {searchTerms}.

Actual result

Sometimes the URL of the search plugin icon (data:image/png;base64,[string] or moz-extension://[string]) becomes the {searchTerms} instead.
Please see the attached video for reference. (Yellow: left-click; green: right-click)

Notes

1. This bug exhibits only with right-clicks-to-search, not left- nor middle-clicks in my testing (around 20 tries for each mouse button).
2. This bug exhibits on right-clicks no matter in where the search opens: current tab, new tab, new window; it is customisable in the extension's settings.
3. This bug exhibits 10-20% of the time in a new profile, but over 80% in my main profile.

Regression

Last good Nightly: 2025-11-23
First bad Nightly: 2025-11-24
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dca44e6b1f207d2693e9be71ce2e04454223e339&tochange=87bd2ca15e2a177ee5123d4ac190881476c8379c

Bisecting autoland builds:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=37f1c536fdb89cd69039774a87f3ad8a94b95328&tochange=86c4f03a43058ea62f76021ad5a50e6199c34567

This is regressed by bug 543435.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:vhilla, since you are the author of the regressor, bug 543435, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Vincent Hilla [:vhilla]]

Thanks for the report.

The extension says that right-click-to-search might not work on systems that show the context menu on mousedown. So I cannot test this on Linux right now.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Bug 543435 was reverted from Fx147. Updating the flags accordingly.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 5

[Vincent Hilla [:vhilla]]

I'll keep this on my list and try to get to it after some of the other regressions.

Comment 6

[Donal Meehan [:dmeehan]]

This might not get a fix in time for Fx148, but we should still look for a fix for Fx149

Comment 7

[Vincent Hilla [:vhilla]]

I can't reproduce this. I tried 20 context searches, with Linux and Windows Nightly, new profiles.

When content is selected, a "updateSearchTerms" message is sent around. And openSearch in background.js uses these searchTerms to open some search engine. This contextsearch-widgets element lives in content and one of it's images could become selected. But the video indicates the selection didn't change.

---

Fanolian, can you try to record a profile with the Web Compat settings?

• Open https://profiler.firefox.com/ and enable the profiler button
• Next to the profiler button, open the dropdown and select Web Compat
• Then start the profiler, reproduce the issue, stop it
• On the profile that opens, click upload and share the link

Comment 8

[Fanolian]

https://share.firefox.dev/49nHb3Q

This is a profile captured with the STR in comment 0 on a new Nightly profile created for this capture.
The bug occurred on the 3rd try, started at around 6.5s in the profile.

Comment 9

[Vincent Hilla [:vhilla]]

Thanks!

I see there is some race going on.

• When a document is created, init_content.js is injected and sends injectContentScripts to the background script.
• The context search menu is opened by inject_quickmenu.js makeMenuWindow. This method binds an iframe to the DOM before setting src and bug 543435 has the impact that there will now be a fully loaded about:blank.
• This causes init_content.js to be injected into this about:blank. If I change makeMenuWindow to set src earlier, the script is never inserted. Are content scripts not inserted into extension pages?
• As response to injectContentScripts, the background script does all kinds of processing and tries to inject more scripts into the iframe.
• I think this processing and inserting of scripts races with the load for quickmenu.html.
  • For example, a function is inserted to check if the content document contains an html element. This flakily returns true or undefined and flakily runs in about:blank or quickmenu.html

I'll need to create a minimal example and figure out whether similar races occur in Chrome.

Comment 10

[Vincent Hilla [:vhilla]]

I think inserting these isHTML or isTabScriptable functions sometimes fails with

Error: Missing host permission for the tab or frames

if they are inserted into this quickmenu.html document. If they do fail, we won't insert the content scripts, won't have the mousedown listener.

Comment 11

[Vincent Hilla [:vhilla]]

Chrome also has this init_content.js that runs in the initial about:blank before it's replaced by quickmenu.html.

But in the context search background service worker logs for Chrome, I always see

Uncaught (in promise) Error: Cannot access contents of url "chrome-extension://jfgfodjbohdgnhgkfbbgmgjlihoamhep/quickmenu.html". Extension manifest must request permission to access this host.

---

:robwu, I think the issue is that in Firefox, the extension sometimes gets to executeScript in this moz-extension://.../quickmenu.html document.

• The extension has different manifests for Chrome and Firefox. Is it maybe only allowed for Firefox?
• Is there a known difference in whether we allow extensions to executeScript from a background script in their own content windows?
• Regarding this

Error: Missing host permission for the tab or frames

it is raised here when !results.length. Could it be possible that the document just went away while trying to execute the script, rather than the permission missing?

If this is expected, maybe we should talk to the extension developers / open a PR to change makeMenuWindow.

Comment 12

[Rob Wu [:robwu]]

The extension has always had a bug, but it is now more likely to trigger. I have reported this to the extension at https://github.com/ssborbis/ContextSearch-web-ext/issues/853

The behavioral change by bug 543435 is that content scripts observably also run in about:blank when an iframe is loaded as follows:

var frame = document.createElement("iframe");
document.body.append(frame);
frame.src = "https://example.com";

Before bug 543435 was fixed, the content script did not run in the initial about:blank document when another load was started after it.

Note that if we swap the order of src assignment and the frame insertion, then the content script executes only once, when example.com is loaded:

var frame = document.createElement("iframe");
frame.src = "https://example.com";
document.body.append(frame);

The behavior observed above is consistent between Chrome and Firefox (with the patch).

---

I looked at the extension, and what it does in short is:

1. Create iframe, insert in document. Change src to extension URL (browser.runtime.getURL('quickmenu.html')).
2. manifest.json declares a content script that runs everywhere, in all frames, at document_start. In child frames with URL about:blank, this script immediately send a message to the background page.
   • Note that the <iframe> created at step 1 is matched here, so the script runs immediately.
3. When the background receives the message, it calls scripting.executeScript to execute code in the specific iframe.
   • The expectation is to run in the same document as the sender of step 2.
   • But due to the navigation initiated at step 1, the document could have changed to the extension URL in the meantime.
   • This is a TOCTOU issue described before in https://github.com/w3c/webextensions/issues/8 . The extension should inject with documentId, not frameId (but we do not support documentId yet, tracked in bug 1891478).

The extension should check in its content script that it is still in the right frame before injecting.
Another work-around is to simply assign the src to the iframe before inserting the iframe. This is also a better practice.

I have posted these recommendations and more at https://github.com/ssborbis/ContextSearch-web-ext/issues/853