Closed
Bug 1379508
Opened 7 years ago
Closed 7 years ago
<select> dropdowns don't work in OOP popup browsers
Categories
(WebExtensions :: Frontend, defect, P1)
Tracking
(firefox56 affected)
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox56 | --- | affected |
People
(Reporter: streetwolf52, Assigned: kmag)
References
(Blocks 1 open bug)
Details
Attachments
(7 files)
15.11 KB,
image/png
|
Details | |
59 bytes,
text/x-review-board-request
|
kats
:
review+
|
Details |
59 bytes,
text/x-review-board-request
|
kats
:
review+
jimm
:
review+
|
Details |
59 bytes,
text/x-review-board-request
|
zombie
:
review+
|
Details |
12.96 KB,
image/png
|
Details | |
236.09 KB,
image/gif
|
Details | |
7.20 MB,
application/x-zip-compressed
|
Details |
Bug 1357486 has partially broken at least one WE add-on I use. It is called Zoom Page WE. The drop-down lists on the main menu to change font size and zoom level do not display. The screen shot I provided shows the two areas, when clicked on, should produce a drop-down menu of font sizes and zoom levels. Setting pref 'extensions.webextensions.remote = false' makes the add-on work correctly.
Reporter | ||
Comment 1•7 years ago
|
||
Found another WE add-on of mine that doesn't produce a drop down list when I click on the down arrow in it's options in the Extensions list. The add-on is called AutoplayStopper 0.9.8.
Reporter | ||
Updated•7 years ago
|
Summary: Webextensions add-on 'Zoom Page WE' partially broken by Bug 1357486. → Some Webextensions add-ons partially broken by Bug 1357486.
Search Site WE popup don't shows if extensions.webextensions.remote=true. Maybe it is an same problem?
Reporter | ||
Comment 3•7 years ago
|
||
(In reply to YF (Yang) from comment #2)
> Search Site WE popup don't shows if extensions.webextensions.remote=true.
> Maybe it is an same problem?
I'm sure it is as it is by the same developer
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → kmaglione+bmo
Blocks: webext-oop
Status: UNCONFIRMED → NEW
Component: WebExtensions: General → WebExtensions: Frontend
Ever confirmed: true
Summary: Some Webextensions add-ons partially broken by Bug 1357486. → <select> dropdowns don't work in OOP popup browsers
Comment 4•7 years ago
|
||
Add ForecastFox 4.1 to the list of broken WE extensions with drop-list.
Comment hidden (me-too) |
Reporter | ||
Comment 6•7 years ago
|
||
Folks, no need to spam this report. It appears all WE add-ons with dropdown menus are broken. Adding your particular add-on just adds to the clutter.
btw... what is the priority for this report?
Comment 7•7 years ago
|
||
Yes, as Gary said, no need to me-too this bug.
And I'd say this is P1 as well, considering it's blocking bug 1357486.
Priority: -- → P1
Reporter | ||
Comment 8•7 years ago
|
||
Is the patch to fix this issue going to be released soon? I ask as a Nighty Tester who needs some of my broken add-ons to be fully functional. No spam intended.
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 12•7 years ago
|
||
mozreview-review |
Comment on attachment 8886417 [details]
Bug 1379508: Part 1 - Apply the correct client offsets to remote frameloaders in popup widgets.
https://reviewboard.mozilla.org/r/157216/#review162504
::: dom/ipc/TabParent.cpp:2005
(Diff revision 1)
> + return (docWidget->GetClientOffset() -
> + nsLayoutUtils::WidgetToWidgetOffset(docWidget, widget));
minor nit: I would find this slightly easier to read if you swapped the order of arguments to WidgetToWidgetOffset and changed the minus to a plus. That way WidgetToWidgetOffset returns a (likely positive) distance from widget to docWidget, which you are then adding to docWidget's existing client offset.
Attachment #8886417 -
Flags: review?(bugmail) → review+
Comment 13•7 years ago
|
||
mozreview-review |
Comment on attachment 8886418 [details]
Bug 1379508: Part 2 - Ignore transforms when calculating child process offsets.
https://reviewboard.mozilla.org/r/157218/#review162508
I'll give this an r+ if it's green on try, but I'll be honest - my understanding of this is pretty shaky. I don't know if anybody fully understands all of this though. smaug or jimm might be good bets if you want a second review.
::: dom/ipc/TabParent.cpp:1989
(Diff revision 1)
> - nsPoint pt = nsLayoutUtils::GetEventCoordinatesRelativeTo(widget,
> - LayoutDeviceIntPoint(0, 0),
> - targetFrame);
>
> - return LayoutDeviceIntPoint::FromAppUnitsToNearest(
> - pt, targetFrame->PresContext()->AppUnitsPerDevPixel());
> + nsPresContext* presContext = targetFrame->PresContext();
> + nsIFrame* rootFrame = presContext->PresShell()->FrameManager()->GetRootFrame();
can rootFrame be null here? Usually stuff returned by "Get" functions (GetRootFrame() in this case) is allowed to be null. If so you might need a guard.
Attachment #8886418 -
Flags: review?(bugmail) → review+
Assignee | ||
Comment 14•7 years ago
|
||
mozreview-review-reply |
Comment on attachment 8886418 [details]
Bug 1379508: Part 2 - Ignore transforms when calculating child process offsets.
https://reviewboard.mozilla.org/r/157218/#review162508
> can rootFrame be null here? Usually stuff returned by "Get" functions (GetRootFrame() in this case) is allowed to be null. If so you might need a guard.
It shouldn't be possible for it to be null in this case, since already have a frame in the same presContext, and there needs to be a root frame for it to inherit from. I'm not opposed to adding a guard, though.
Assignee | ||
Updated•7 years ago
|
Attachment #8886418 -
Flags: review?(jmathies)
Comment 15•7 years ago
|
||
mozreview-review |
Comment on attachment 8886419 [details]
Bug 1379508: Part 3 - Support <select> popups in OOP popup browsers.
https://reviewboard.mozilla.org/r/157220/#review162660
::: browser/components/extensions/test/browser/browser-remote.ini:12
(Diff revision 1)
> # whether we're running from that directory from head.js
> install-to-subdir = test-oop-extensions
> tags = webextensions remote-webextensions
> skip-if = !e10s
>
> +[browser_ext_popup_select.js]
What's the reason for this only running in OOP mode?
::: browser/components/extensions/test/browser/browser_ext_popup_select.js:8
(Diff revision 1)
> +"use strict";
> +
> +add_task(async function testPopupSelectPopup() {
> + let extension = ExtensionTestUtils.loadExtension({
> + background() {
> + browser.tabs.query({active: true, currentWindow: true}, tabs => {
nit: async
::: browser/components/extensions/test/browser/browser_ext_popup_select.js:63
(Diff revision 1)
> + });
> +
> + let {boxObject} = browser;
> + let popupRect = selectPopup.getOuterScreenRect();
> +
> + is(Math.floor(boxObject.screenX + elemRect.left), popupRect.left,
Are all of these coordinates affected by `devicePixelRatio` in the same way?
::: browser/components/extensions/test/browser/browser_ext_popup_select.js:73
(Diff revision 1)
> + clickBrowserAction(extension);
> + let browser = await awaitExtensionPanel(extension);
This always looks like a race condition to me :/
Attachment #8886419 -
Flags: review?(tomica) → review+
Assignee | ||
Comment 16•7 years ago
|
||
mozreview-review-reply |
Comment on attachment 8886419 [details]
Bug 1379508: Part 3 - Support <select> popups in OOP popup browsers.
https://reviewboard.mozilla.org/r/157220/#review162660
> What's the reason for this only running in OOP mode?
In-process select popups work differently. They don't use a XUL popup.
> Are all of these coordinates affected by `devicePixelRatio` in the same way?
They all use the same coordinate system, yes.
> This always looks like a race condition to me :/
It's not. The WebExtPopupLoaded event is always dispatched asynchronously.
Assignee | ||
Comment 17•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/61913ebf8097a519e90c16c3a299858a462d10ab
Bug 1379508: Part 1 - Apply the correct client offsets to remote frameloaders in popup widgets. r=kats
https://hg.mozilla.org/integration/mozilla-inbound/rev/58e9c32d5e53f119a3a909b836496efaf073298b
Bug 1379508: Part 2 - Ignore transforms when calculating child process offsets. r=kats
https://hg.mozilla.org/integration/mozilla-inbound/rev/709cedd7f1bafd43c0be6e6c642d3d497e65c108
Bug 1379508: Part 3 - Support <select> popups in OOP popup browsers. r=zombie
Assignee | ||
Comment 18•7 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #13)
> I'll give this an r+ if it's green on try, but I'll be honest - my
> understanding of this is pretty shaky. I don't know if anybody fully
> understands all of this though. smaug or jimm might be good bets if you want
> a second review.
Landing now with just your review, since it fixes problems for nightly users, but leaving the review flag for jimm in case it needs a follow-up.
Assignee | ||
Comment 19•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/41b75de6ceb270bf87f1b965052d37cdc64f511a
Bug 1379508: Follow-up: Disable select popup test on OS-X for alignment issues.
Reporter | ||
Comment 20•7 years ago
|
||
Getting close but no cigar as they say. As seen in the screenshot there is a small popup 'above' the zoom percentage. Same thing happens to the font size.
The other add-on I have does seem to work however, Textarea Cache Lite. It doesn't having the same sort of dropdown menu but it does work now.
Reporter | ||
Comment 21•7 years ago
|
||
Another WE add-on, AutoplayStopper, doesn't display it's dropdown lists at all when the down arrow is clicked.
Assignee | ||
Comment 22•7 years ago
|
||
(In reply to Gary [:streetwolf] from comment #20)
> Getting close but no cigar as they say. As seen in the screenshot there is
> a small popup 'above' the zoom percentage. Same thing happens to the font
> size.
That's expected. Select popups for remote frames are constrained to the viewport of the page. Feel free to file a separate bug if you think that should be changed.
Assignee | ||
Comment 23•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/43676eab0672b3e86b33dcad9d672ac07e4c562f
Bug 1379508: Follow-up: Disable select popup test on Linux for frequent intermittent failures.
Reporter | ||
Comment 24•7 years ago
|
||
Kris.
It also appears your fix screws up resizing windows for the WE add-ons I use. One window just disappears when I try to drag the resize icon on the bottom right. Another one, on it's Extensions page, makes the window one line. Is this expected behavior too?
Comment 25•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/61913ebf8097
https://hg.mozilla.org/mozilla-central/rev/58e9c32d5e53
https://hg.mozilla.org/mozilla-central/rev/709cedd7f1ba
https://hg.mozilla.org/mozilla-central/rev/41b75de6ceb2
https://hg.mozilla.org/mozilla-central/rev/43676eab0672
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox56:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Comment 26•7 years ago
|
||
Just tested the latest m-c win32 build with this patch and ForecastFox is still not showing drop-down.
Comment 27•7 years ago
|
||
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #26)
> Just tested the latest m-c win32 build with this patch and ForecastFox is
> still not showing drop-down.
You should try the tomorrow Nightly (m-c). Check the push date on about:buildconfig and comment 25.
Reporter | ||
Comment 28•7 years ago
|
||
I'm on inbound with the patch and as I said in a previous comment things are not as they were. The dropdown looks different in some instances or they still don't work.
Comment 31•7 years ago
|
||
mozreview-review |
Comment on attachment 8886418 [details]
Bug 1379508: Part 2 - Ignore transforms when calculating child process offsets.
https://reviewboard.mozilla.org/r/157218/#review163088
Attachment #8886418 -
Flags: review?(jmathies) → review+
Comment 32•7 years ago
|
||
mozreview-review-reply |
Comment on attachment 8886418 [details]
Bug 1379508: Part 2 - Ignore transforms when calculating child process offsets.
https://reviewboard.mozilla.org/r/157218/#review162508
I know very little about the transforms stuff tbh. I know about widget offsets but that's not relevant here. sorry.
Comment 33•7 years ago
|
||
Setting the status flag back to affected and reopening the bug, since there were reports of the issue still existing and there's now a new patch to land.
Assignee | ||
Comment 34•7 years ago
|
||
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #33)
> Setting the status flag back to affected and reopening the bug, since there
> were reports of the issue still existing and there's now a new patch to land.
The reports were of other issues. This issue is fixed. And the follow-up has landed, in any case.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Comment 35•7 years ago
|
||
Hello guys,
It seems I encountered the Bug 1380294 on Firefox 56.0a1 (2017-07-20) under Win7 64-bit , please have a look at the attached video.
Flags: needinfo?(kmaglione+bmo)
Comment 36•7 years ago
|
||
I tested some WebExtensions like: Forecastfox (fix version), Search Site WE, Zoom Page WE on Firefox 56.0a1(2017-07-24) on Wind 7 64-bit, Wind 10 32-bit, Wind 10 64-bit, Ubuntu 16.04 32-bit and Mac OS X 10.12.3.
Forecastfox (fix version) is not working on Wind 10 32-bit, Wind 10 64-bit, Ubuntu 16.04 32-bit and Mac OS X 10.12.3
At some point the extension will crash on Wind 10 32-bit
https://crash-stats.mozilla.com/report/index/d780985d-3741-4d61-9c4d-13ceb0170724
Zoom Page WE, does not display the selected value correctly in the drop-down list after reset.
Do you have any opinion about these issues Kris?
Please see the attached videos.
Comment 37•7 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #22)
> (In reply to Gary [:streetwolf] from comment #20)
> > Getting close but no cigar as they say. As seen in the screenshot there is
> > a small popup 'above' the zoom percentage. Same thing happens to the font
> > size.
>
> That's expected. Select popups for remote frames are constrained to the
> viewport of the page. Feel free to file a separate bug if you think that
> should be changed.
Kris,
I'm fairly sure that this fix does not work correctly and has introduced new problems.
Specifically, I am experiencing problems with the select drop-downs in two of my WebExtensions add-ons: Zoom Page WE and Tile Pages WE.
In the case of Zoom Page WE, the select element is inside the browserAction popup. With Firefox 54, the select drop-down is allowed to extend outside the browserAction popup window. With Nightly 56, I understand that the select drop-down should be constrained to the browserAction popup window. However, the select drop-down is NOT displayed at all, and even if I make the browserAction popup window big enough to contain the entire select drop-down, it still is NOT displayed.
In the case of Tile Pages WE, the select elements are inside the add-on Options window. With Firefox 54, the select drop-downs are displayed correctly. With Nightly 56, the select drop-downs are NOT displayed, even though the add-on Options window is definitely big enough to contain the select drop-downs.
I cannot believe that this is the new expected behaviour.
Do I need to raise a new bug?
Comment 38•7 years ago
|
||
Kris,
Separately to the bugs reported in Comment 37, there one question I forgot to ask ...
Is there a technical reason why select drop-downs (and popups in general) are not allowed to extend outside the parent page/window? Or is it a user interface design decision?
Either way, is there any chance of getting this decision changed?
Comment 39•7 years ago
|
||
I've looked through a few more WebExtenions add-ons and very quickly found two more add-ons where the select drop-downs do not display in the add-ons Options window: 'LanguageTool Grammar Checker' and 'Page Translator'.
Assignee | ||
Comment 41•7 years ago
|
||
(In reply to dw-dev from comment #38)
> Is there a technical reason why select drop-downs (and popups in general)
> are not allowed to extend outside the parent page/window? Or is it a user
> interface design decision?
Not a technical reason, no.
> Either way, is there any chance of getting this decision changed?
Feel free to file a separate bug.
Flags: needinfo?(kmaglione+bmo)
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•