Nightly: omnibox.onInputChanged.addListener fails

VERIFIED FIXED in Firefox 55

Status

defect
P2
normal
VERIFIED FIXED
2 years ago
10 months ago

People

(Reporter: horridimpfoobarbaz, Assigned: kmag)

Tracking

({regression})

56 Branch
mozilla56

Firefox Tracking Flags

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

Details

(Whiteboard: [triaged])

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
Posted 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.
(Reporter)

Comment 1

2 years ago
Posted 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

2 years ago
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)
(Assignee)

Comment 7

2 years ago
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)

Comment 9

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/2cb8b8e9d1e9
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
(Assignee)

Comment 10

2 years ago
This namespace has schema definitions which spuriously expose it to extension
callers, and does not support lazy loading correctly, which breaks certain
usage patterns.
(Assignee)

Comment 11

2 years ago
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: https://www.screencast.com/t/0zgQhgUMFg
Status: RESOLVED → VERIFIED
Flags: qe-verify+

Updated

10 months ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.