Issue metadata
Sign in to add a comment
|
Chrome extension options UI - right click menu in the wrong place.
Reported by
lbell...@gmail.com,
Mar 21 2016
|
||||||||||||||||||||||
Issue description
Chrome Version : 49.0.2623.87
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) : N/A
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: N/A
Firefox 4.x: N/A
IE 7/8/9: N/A
What steps will reproduce the problem?
1. Create a chrome extension with the new options page (declared in the manifest as "options_ui"). Here is manifest.json:
{
"name": "test",
"version": "1.0",
"manifest_version": 2,
"description": "check out options page bug",
"browser_action": {
"default_popup": "popup.html"
},
"options_ui": {
"page": "options.html"
}
}
2. Add a <select> element with <option> elements to the options page. Here is options.html:
<!DOCTYPE HTML>
<html lang="en">
<head>
<title>test</title>
</head>
<body>
<select>
<option>one</option>
<option>two</option>
<option>three</option>
</select>
</body>
</html>
3. Try right clicking anywhere on the options page.
4. Try clicking on the select menu.
What is the expected result?
-The right click context menu should appear where you clicked.
-The options of the select menu should drop down directly under the <select> element.
What happens instead of that?
-The right click context menu appears in seemingly random locations around the screen.
-The dropdown menu appears in seemingly random locations, not under the <select> element.
Please provide any additional information below. Attach a screenshot if
possible.
The problem goes away if you click the maximize/restore down button, but returns when the options page is refreshed. Attached is a screenshot of the right click menu in the wrong place.
UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
,
Mar 22 2016
lbellist@Could you please confirm whether we can close this issue as per comment #1?
,
Mar 22 2016
No. As I said in the comment, the issue seems to go away when you resize the browser. But as soon as you reload the option page the problem returns.
,
Mar 23 2016
Thank you for providing more feedback. Assigning to requester "ssamanoori@chromium.org" for another review. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 25 2016
This is a regression, it used to work in Chrome 48. a86973e6a92be4540c7d1229e7b3be0148bafd2f is the culprit. When I manually revert this commit, the bug disappears.
,
Apr 1 2016
Remove non-official component, Blink>UI.
,
Apr 4 2016
,
Apr 5 2016
,
Apr 19 2016
My guess is that the problem is removal of the extra loop calling widgetPositionsUpdated in FrameView. That change will adjust the order in which the widgets get the call. I would try re-instituting that before reverting the deletion of "reportGeometry" in WebPluginContainerImpl. Re-assign to me if you're swamped.
,
May 5 2016
,
May 6 2016
The problem is actually the removal of reportGeometry from WebPluginContainerImpl::setFrameRect, which is probably the perf issue. It seems that if setFrameRect is called then frameRectsChanged should be called, so I'll try to see what code sets the frame rects.
,
May 13 2016
In case anyone is googling for this, I just want to point out that this also affects the drop-down box of the select element. It can potentially appear on the wrong monitor in multi-monitor setups.
,
May 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b999309cd9ace1b703df73ed50d1c0d9efde90fa commit b999309cd9ace1b703df73ed50d1c0d9efde90fa Author: schenney <schenney@chromium.org> Date: Thu May 19 17:42:41 2016 Fix positioning of widgets The BrowserPlugin updateGeometry code was only sending a UpdateGeometry message to its host if the rect was the _same_ as the previous rect. This required two calls to the method in order to get the message sent, and no doubt resulted in the message being sent every time the geometry was the same and never when it was different. R=fsamuel@chromium.org, lazyboy@chromium.org BUG= 555201 , 596494 Review-Url: https://codereview.chromium.org/1958903005 Cr-Commit-Position: refs/heads/master@{#394808} [modify] https://crrev.com/b999309cd9ace1b703df73ed50d1c0d9efde90fa/chrome/browser/apps/guest_view/web_view_interactive_browsertest.cc [modify] https://crrev.com/b999309cd9ace1b703df73ed50d1c0d9efde90fa/content/renderer/browser_plugin/browser_plugin.cc
,
May 25 2016
,
May 25 2016
This made the m52 branch but I think it's broken in m51 and probably m50 too. No negative fallout has come from the patch apart from increasing test flakiness (no doubt exacerbating a pre-existing test timing problem).
,
May 25 2016
[Automated comment] Less than 2 weeks to go before stable on M51, manual review required.
,
May 25 2016
Before we approve merge to M51, Could you please confirm whether this change is baked/verified in Canary and safe to merge?
,
May 26 2016
Could you confirm what you mean by baked/verified on Canary? Do you mean "verified as fixed" or do you mean "verified as not causing further issues"? I have verified that it is fixed in m53 Canary, and it landed before the m52 branch, so it should already be fixed in m52 (I'll verify that when I restart my browser). I verified that it is broken in m51 so the merge is necessary if we want to fix the bug. I have not seen any bug reports related to the fix, but then it's not my normal area so I would only know if a bisect blamed me. Is there more I should do?
,
May 27 2016
It means verified as fixed as no regression.
,
May 31 2016
I think that this is verified as fixed causing no regressions. I know it's fixed, and I have seen no evidence at all of further regressions.
,
May 31 2016
Ok, approving merge to M51 branch 2704 based on comment #20. Please merge ASAP as we're cutting M51 Desktop Stable RC today. Thank you.
,
May 31 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/859ed4fe376118092b622b79c99650e13704a3a4 commit 859ed4fe376118092b622b79c99650e13704a3a4 Author: Stephen Chenney <schenney@chromium.org> Date: Tue May 31 16:59:55 2016 Fix positioning of widgets The BrowserPlugin updateGeometry code was only sending a UpdateGeometry message to its host if the rect was the _same_ as the previous rect. This required two calls to the method in order to get the message sent, and no doubt resulted in the message being sent every time the geometry was the same and never when it was different. R=fsamuel@chromium.org, lazyboy@chromium.org BUG= 555201 , 596494 Review-Url: https://codereview.chromium.org/1958903005 Cr-Commit-Position: refs/heads/master@{#394808} (cherry picked from commit b999309cd9ace1b703df73ed50d1c0d9efde90fa) Review URL: https://codereview.chromium.org/2021363002 . Cr-Commit-Position: refs/branch-heads/2704@{#683} Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251} [modify] https://crrev.com/859ed4fe376118092b622b79c99650e13704a3a4/chrome/browser/apps/guest_view/web_view_interactive_browsertest.cc [modify] https://crrev.com/859ed4fe376118092b622b79c99650e13704a3a4/content/renderer/browser_plugin/browser_plugin.cc
,
Jun 1 2016
Tested the issue on Windows 7 using 51.0.2704.78 as per steps in comment #0.Observed that the right click context menu appeared where we clicked and the options of the select menu drop down directly under the <select> element. Please find attached screencast. Marking it as TE-Verified.
,
Jun 1 2016
Tested the issue on Windows 7 using 51.0.2704.79 as per steps in comment #0 and it is working fine. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by lbell...@gmail.com
, Mar 21 2016