Closed Bug 1488991 Opened 3 years ago Closed 1 year ago

Contextual menu is opening at the wrong position

Categories

(DevTools :: Responsive Design Mode, defect, P3)

64 Branch
defect

Tracking

(firefox67 verified, firefox68 verified, firefox69 verified)

RESOLVED DUPLICATE of bug 1556962
Firefox 67
Tracking Status
firefox67 --- verified
firefox68 --- verified
firefox69 --- verified

People

(Reporter: karlcow, Assigned: daisuke)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [dt-q])

Attachments

(1 file)

With Firefox Nightly 64 (but it has been happening for ages)

0. on macOS (with a macbook with click on tap)
1. Go to https://www.mozilla.org/en-US/
2. Make the window small enough around 500px (leave space on the left side)
3. Activate responsive design mode
4. ctrl tap anywhere in the RDM viewport
   The contextual menu is displayed
5. (WITHOUT closing the contextual menu) move your cursor on the left side of the browser window to resize the window toward the left
6. Resize the window (double the size for example)
   The contextual menu disappears. (that's normal)
7. Ctrl tap again on the same area you did before.

Actual:
The contextual menu is opening shifted on the right side.

Expected:
The contextual menu should open at the place which has been tapped. 


(The Website is irrelevant. I can reproduce anytime.)
Whiteboard: [dt-q]
Priority: -- → P3
Duplicate of this bug: 1494450
Duplicate of this bug: 1506193
Blocks: rdm-ux
Assignee: nobody → dakatsuka
Status: NEW → ASSIGNED

The position of remote browser was not updated by resizing the window and
changing the align of viewport etc, although will be updated when the window
moves, the frame reflows and so on.
Thus, in this patch, update the position of remote browser before showing
context menu so as to locates at proper position.
I investigated though, when reflow and moving happens, the position is updated
by TabParent::UpdateDimensions()[1]. This patch as well is taking an approach
which update the position explicitly by TabParent::UpdateDimensions() before
showing context menu.

[1] https://searchfox.org/mozilla-central/source/dom/ipc/TabParent.cpp#729

This smells similar to https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/base/content/webext-panels.js#99-108
See the blame.
Also that js code is hacky, but I don't mind using same approach in devtools, but want to file a new bug to sort out the issue properly. Explicit update from JS shouldn't be needed.

Ah, it looks like same issue. Yup, I will use requestUpdatePosition() at this moment though, will file a bug that the position of remote frame does not update automatically. Thank you so much!

Attachment #9050920 - Attachment description: Bug 1488991: Update remote browser position before showing context menu. r?Honza,r?pbro → Bug 1488991: Update remote browser position before showing context menu. r?smaug,r?pbro
Pushed by dakatsuka@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9d33ee85f2d4
Update remote browser position before showing context menu. r=pbro,smaug
See Also: → 1535515
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
QA Whiteboard: [qa-67b-p2]
Duplicate of this bug: 1461796

Hi,

The issue is still reproducible in latest Nightly build 69.0a1 (2019-06-04) on Windows 10 and Windows 7. On Ubuntu 18.04 and Mac OS 10.14 cannot reproduce it.
Note: The issue occurs just with touch simulation enabled.
Should I reopen this bug or create a new one?

Thanks.

Flags: needinfo?(dakatsuka)

Hi Alin, thank you for your report!
Could you file as new bug??

Flags: needinfo?(dakatsuka)

Hi Guys we managed to reproduce this issue in Firefox Nightly 69.0a1 (2019-06-04) on MAC 10.14 as well as Ubuntu.

  1. Open Firefox and set devtools.responsive.metaViewport.enabled = true in about:config.
  2. Restart the browser.
  3. Open any website and Turn on RDM.
  4. Resize the RDM window to 500px.
  5. Enable Touch Simulation.
  6. Right click in various places.

Should We reopen this issue ?

Flags: needinfo?(dakatsuka)

Hi Rares, thank you for you reporting!
This might be a regression from other patches as it works well in Firefox Release 67.0.1 and Beta 68.0b7.
Thus, should we file as new?

Flags: needinfo?(dakatsuka)

It still happens in Beta, Only Release is spared.

We already Filed a new bug for Windows, maybe we can add the OS's to that bug ? and close this issue ? I still think we should reopen this one.

Flags: needinfo?(dakatsuka)

Let's use the newly filed bug 1556962 for this and leave this one closed. This appears to be a new issue due to a regression. So having its own dedicated bug feels like the right thing to do.
Also it might be different because it only occurs with touch simulation and the pref on, while this bug maybe didn't require those conditions.

Flags: needinfo?(dakatsuka)

Based on the Steps from the Description This issue is Verified as Fixed in Nightly 69.0a1 (2019-06-05) as well as Release and Beta.

Status: RESOLVED → VERIFIED
See Also: → 1556962
See Also: 1556962
See Also: → 1556962

Still not fixed, or regressed. Now tracking in Bug 1556962.

Status: VERIFIED → RESOLVED
Closed: 2 years ago1 year ago
Resolution: FIXED → DUPLICATE
Duplicate of bug: 1556962
You need to log in before you can comment on or make changes to this bug.