Closed Bug 1375002 Opened 5 years ago Closed 5 years ago

Nightly: omnibox.onInputChanged.addListener fails


(WebExtensions :: Frontend, defect, P2)

56 Branch


(firefox-esr52 unaffected, firefox54 unaffected, firefox55 verified, firefox56 verified)

Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- verified
firefox56 --- verified


(Reporter: horridimpfoobarbaz, Assigned: kmag)



(Keywords: regression, Whiteboard: [triaged])


(3 files)

Attached file background.js
User Agent: Mozilla/5.0 (X11; Linux i686; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170620100236

Steps to reproduce:

Open the addon debugger and load the attached WebExtension. Try using it: type 'example foo' in the location bar, and you should get a dummy suggestion.

Actual results:

No suggestions are provided. in the addon debugger, the error is 'TypeError: handler is undefined', in ExtensionParent.jsm, line 681.
Attached file manifest.json
Component: Untriaged → WebExtensions: Frontend
Product: Firefox → Toolkit
I ran into this the other day. I found that if I call setDefaultSuggestion before adding the listener, then everything works fine.
Ever confirmed: true
Assignee: nobody → mwein
Priority: -- → P2
Whiteboard: [triaged]
Daniela is looking into getting the regression window…
Looks like bug 1350522 was the culprit, perhaps because the API isn't loaded until we call setDefaultSuggestion?  :)
Has Regression Range: --- → yes
Flags: needinfo?(kmaglione+bmo)
This is happening because, for some reason, the parent side of this API has an "omnibox_internal" namespace that the child-side onInputChanged event uses, and it isn't setup for lazy loading.
Assignee: mwein → kmaglione+bmo
Flags: needinfo?(kmaglione+bmo)
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
This namespace has schema definitions which spuriously expose it to extension
callers, and does not support lazy loading correctly, which breaks certain
usage patterns.
Comment on attachment 8883668 [details] [diff] [review]
Get rid of the omnibox_internal namespace

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1350522
[User impact if declined]: This causes certain add-ons which use the omnibox API to fail.
[Is this code covered by automated tests?]: Yes, though the specific bug is not, since it depends on the ordering of API calls during the entire length of the browsers session, and we can't reasonably test variations on that.
[Has the fix been verified in Nightly?]: No
[Needs manual test from QE? If yes, steps to reproduce]: Described in comment 0
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: It's a trivial change to merge an unnecessary internal namespace into the normal namespace for this API.
[String changes made/needed]: None
Attachment #8883668 - Flags: approval-mozilla-beta?
Comment on attachment 8883668 [details] [diff] [review]
Get rid of the omnibox_internal namespace

fix regression affecting webextensions in beta55
Attachment #8883668 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Needs a rebased patch for Beta.
Flags: needinfo?(kmaglione+bmo)
Flags: qe-verify+
I was able to reproduce the initial error on Firefox 56.0a1 (2017-06-21) under Windows 10 64-bit.

Verified fixed on Firefox 56.0a1 (2017-07-25) under Windows 10 64-bit and Ubuntu 16.04 32-bit. 'TypeError: handler is undefined' error is no longer thrown in Browser Console. See screenshot:
Flags: qe-verify+
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.