1488991 - Contextual menu is opening at the wrong position

Status: RESOLVED DUPLICATE of bug 1556962

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

Description

[Karl Dubost💡 :karlcow]

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.)

Comment 3

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1488991: Update remote browser position before showing context menu. r?smaug,r?pbro

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

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 5

[Daisuke Akatsuka (:daisuke)]

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!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9d33ee85f2d4
Update remote browser position before showing context menu. r=pbro,smaug

Comment 7

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/9d33ee85f2d4

Comment 9

[Alin Ilea, Desktop QA]

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.

Comment 10

[Daisuke Akatsuka (:daisuke)]

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

Comment 11

[Alin Ilea, Desktop QA]

Hi,

Sure, this is the new bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1556962

Comment 12

[Rares Doghi, Desktop QA]

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 ?

Comment 13

[Daisuke Akatsuka (:daisuke)]

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?

Comment 14

[Rares Doghi, Desktop QA]

It still happens in Beta, Only Release is spared.

Comment 15

[Rares Doghi, Desktop QA]

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.

Comment 16

[Patrick Brosset <:pbro>]

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.

Comment 17

[Rares Doghi, Desktop QA]

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.

Comment 18

[Brad Werth [:bradwerth]]

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