privatebrowsing support for omnibox api
Categories
(WebExtensions :: General, enhancement, P1)
Tracking
(firefox67 verified)
Tracking | Status | |
---|---|---|
firefox67 | --- | verified |
People
(Reporter: mixedpuppy, Assigned: mixedpuppy)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
I want to prevent the events being fired in ext-omnibox. I was investigating this, I see that we do not know what window any given search is initiated from. I was wondering if you have any ideas around this.
One thought I have is to just check the topmost window, seems that is likely the only place we'd get a omnibox notice from.
Comment 2•6 years ago
|
||
Using the topmost window doesn't sound like a good solution. It looks like ExtensionSearchHandler.jsm is the current bridge between the location bar and extensions and it just has the minimum amount of stuff needed, I would say we should add the browser or window to the state it maintains for an input session. However, the location bar is in the middle of a major overhaul, we should definitely check in with the search folks before modifying any of this code. Mike, what say you?
Assignee | ||
Comment 3•6 years ago
|
||
Comment 4•6 years ago
|
||
Well, I say: use the topmost window if there's no other solution possible. If it's possible, I'd certainly go for passing the addressbar or its ownerGlobal around in the state.
We're indeed working on a rewrite of the addressbar results popup, but the input is staying as it currently is.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 5•6 years ago
|
||
Assignee | ||
Comment 6•6 years ago
|
||
Comment 8•6 years ago
|
||
bugherder |
This issue is verified as fixed on Firefox 67.0a1(20190219213951) under Win 7 64-bit and Mac OS X 10.14.1.
Please see the attached video.
Description
•