Closed Bug 1696786 Opened 4 years ago Closed 4 years ago

Extension browser action popups eat touch events on whole browser

Categories

(WebExtensions :: General, defect)

Product:
WebExtensions
Component:
General
Version:
Firefox 86
Type:
defect

Tracking

(firefox-esr91 wontfix, firefox86 wontfix, firefox87 wontfix, firefox88 wontfix, firefox93 wontfix, firefox94 wontfix, firefox95 wontfix, firefox96 verified)

Status:
VERIFIED FIXED
Milestone:
96 Branch
Tracking Flags:
Tracking Status
firefox-esr91 --- wontfix
firefox86 --- wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 --- verified

People

(Reporter: withtape, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

log
451.24 KB, text/plain
Details
Stack of nsXULPopupManager::Rollup()
15.81 KB, text/plain
Details
Bug 1696786 - Fix a couple bugs in Windows rollup code. r=cmartin,mhowell
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

On Windows 10 Pro 2004 (build 19041.804) on a Surface Pro 6, I use the touchscreen to tap a browser action button for an extension (any extension) that shows a popup, and then touch anywhere within the popup.

Actual results:

The popup vanishes and the main browser window ignores all further touch events, including on the menu bar and the OS "window close" button. The browser will respond to "true" mouse events, such as from a hardware mouse or the OS on-screen trackpad, but does not respond to any direct touch events. Sometimes it will regain touch after a short time passes.

Expected results:

The popup should not disappear; it should interact with touch events as if they were mouse events, and the browser main window should remain responsive.

The Bugbug bot thinks this bug should belong to the 'DevTools::Responsive Design Mode' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Responsive Design Mode
Product: Firefox → DevTools

I have replicated this behaviour on Firefox 86.0 (64-bit), as well as beta 87.0b7 (64-bit) and nightly 88.0a1 (2021-03-07) (64-bit) using Windows 10 Home 20H2 OS Build 19042.804.

Firefox 78.8.0esr (64-bit) is not affected. I'm fairly sure 85.0 was also not affected but have not been able to test this version yet.

Steps I used to replicate - noting that this does require a touch capable device.

Install latest Firefox (86).
Install the addon "Firefox Multi-Account Containers".
Tap the Multi-Account Containers icon on the toolbar.
The "first use" GUI pops up.
Attempt to touch the blue "Get Started" button. Nothing happens - the popup GUI sometimes disappears but not always for me. Touch now no longer works for other Firefox GUI elements.
Mouse events still work, even after touch interaction has stopped.

This impacts all add-ons I've used.

I used a stopwatch to time it, and consistently the browser ignores touch input for right about 60 seconds, and then it starts accepting touch input again. Still not able to interact with the popups.

STRs are not using RDM, moving to WebExtensions

Component: Responsive Design Mode → General
Product: DevTools → WebExtensions

Hello,

We have managed to reproduce the issue fully on one device (Surface Pro) and partially on a second device (Lenovo Yoga), both running Windows 10 Pro, on the latest Nightly (88.0a1/20210311220018), Beta (87.0b9/20210311161514) and Release (86.0.1/20210310152336). Tested with “Firefox Multi-Account Containers” and “uBlock Origin” add-ons.

Both devices were tested with the following:

  1. Tap the toolbar icon
  2. The add-on pop-up is displayed
  3. Tap any button from the pop-up
  4. The pop-up closes/disappears
    5a. On the Surface Pro, touch no longer works for other Firefox GUI elements
    5b. On the Lenovo Yoga, touch interaction is still possible for other Firefox GUI elements
Status: UNCONFIRMED → NEW
status-firefox86: --- → affected
status-firefox87: --- → affected
status-firefox88: --- → affected
Ever confirmed: true

note: to find someone who works on this layer

Flags: needinfo?(mixedpuppy)
See Also: → 1695680

Do you know who might be best to look into the touch events for this?

Flags: needinfo?(mixedpuppy) → needinfo?(bugs)

Well, first thing is to find regression range.

Flags: needinfo?(bugs)
Keywords: regression, regressionwindow-wanted

Hello and sorry for the delay! It took me a bit to get a hold of someone with a device to be able to test on.

Ran a regression range from 2020.01.01 until today with the following results:

2021-08-04T12:30:29.182000: DEBUG : Found commit message:
Bug 1676956 – Run StreamFilter tests with oop extensions too r=mixedpuppy

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a421fd8b98973bcd6569ccc904523105c7282cd6&tochange=c48c1da239e33debaa714060bcb2df8f20bff1be

I haven't looked closely to the other patches part of the same pushlog, but I'm pretty sure we can exclude Bug 1676956 from the possible regressing changes, the patch landed from it is a test-only change.

Hello,

Wanted to point out that I do not have the device for testing myself so I asked a colleague (which has a Lenovo Yoga to test on) to check for the regression.

Unfortunately, as the only device we have is a Lenovo Yoga at the moment, and as I was just informed that the issue cannot be consistently reproduced on this device, in the sense that sometimes touch interactions are still possible for other Firefox GUI elements and sometimes they are not i.e the issue is at times fully reproduced and at times partially reproduced, we cannot properly narrow down the regression.

The only issue that could be consistently reproduced was the add-on popup GUI closing when interacting with pop-up buttons.

Taking into consideration the info above, we ran a couple of more bisections and found these:

Bug 1690469 – [remote] Reorganize Remote Agent Rust module. r=remote-protocol-reviewers,jgraham

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d1239fdf8725420424d86c05b834c56993eeef35&tochange=a997c2b34b369bf33135ca52b24c45827f281355

and in a second bisection:

Bug 1691814 – [remote] Improve failure message for timestamp assertions. r=remote-protocol-reviewers,jdescottes

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6c32d769ff9a1ad140d62f94dc4f7af97fa3f696&tochange=226b7b7e0ee82bcc8c45fe8ae431a29755afb7d5

Hello,
I am using,
Hardware: Surface pro 6
OS: Windows 10 ltsc 2019, Windows 11 (22000.258), Windows Server LTSC 2022
Firefox: Firefox 93 (64bit) portableapps.com
Extension in test: Ublock Origin, Decentraleyes.
input device: Touchscreen
user js: arkenfox

how to reproduce:

  1. go to https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search
  2. add to firefox
  3. press on decentraleyes icon
  4. try pressing any icon like settings.

what happened:
nothing, like the click is registered on the background and not on the addons popup

what i expect:
it will go to setting page

Have I tried other extensions:
it also happened to ublock origin

Could someone who is able to reproduce this please check if the following resolves the issue:

  • go to about:config
  • set the pref apz.popups.enabled to false
  • restart the browser

Thanks!

(In reply to Botond Ballo [:botond] from comment #17)

Could someone who is able to reproduce this please check if the following resolves the issue:

  • go to about:config
  • set the pref apz.popups.enabled to false
  • restart the browser

Thanks!

This resolves it for me on Firefox 93 (Surface Pro 6, Windows 10)!

Thanks for checking. I believe that confirms bug 1493208 as the regression window we're looking for (and also hopefully provides a workaround until the issue is properly fixed).

Keywords: regressionwindow-wanted
Regressed by: 1493208
Has Regression Range: --- → yes

Emilio kindly told me that he will do some volunteering works for this issue.

So a first good step to diagnose is to get some APZ related to log with MOZ_LOG="apz.controller:5,apz.manager:5,apz:inputstate:5,apz:inputqueue:5".

A STR is in comment 2. Thanks!

Flags: needinfo?(emilio)
Attached file log —

This log is from running:

MOZ_LOG="apz.controller:5,apz.manager:5,apz:inputstate:5,apz:inputqueue:5" mach run  --temp-profile https://addons.mo zilla.org/en-US/firefox/addon/multi-account-containers/ >log 2>&1

But note that even though I can reproduce the popup closing too soon, the UI keeps being responsive.

Flags: needinfo?(emilio)

Hope the above helps, do you need something else? If not, happy to help. Happy to try debugging this locally as well with a few pointers too.

Flags: needinfo?(hikezoe.birchill)

Here's some preliminary analysis of the logs. There are three different APZCTreeManager instances in total, suggesting three different windows. Each has a chrome APZC and a content APZC.

APZCTreeManager 1e105504600
chrome APZC 1e1796e5000 (composition bounds dimensions 357 x 542)
content APZC 1e1796e0000

APZCTreeManager 1e105505200
chrome APZC 1e1796f8800 (composition bounds dimensions 3205 x 1926)
content APZC 1e10a161800

APZCTreeManager 1e10deed800
chrome APZC 1e1796e8000 (composition bounds dimensions 774 x 1004)
content APZC 1e1796e5000

I'm not sure what the first window is, but it's only present for a little bit at the beginning of the log. From the composition bounds dimensions, we can infer that the second window is the main browser window, and the third window is the pop-up window.

Now looking at what APZCs receive what input events:

$ grep -E "got a.*in state" log.txt
[GPU 7024: Main Thread]: D/apz.controller 1e10a161800 got a touch-start in state 0
[GPU 7024: Main Thread]: D/apz.controller 1e10a161800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e10a161800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e10a161800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e10a161800 got a single-tap-up in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e10a161800 got a touch-end in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a touch-start in state 0
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a single-tap-up in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796f8800 got a touch-end in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a touch-start in state 0
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a touch-move in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a single-tap-up in state 2
[GPU 7024: Main Thread]: D/apz.controller 1e1796e5000 got a touch-end in state 2

There are three touch blocks in total, each one is a single-tap

  • the first targets the content of the browser window
  • the second targets the chrome of the browser window (presumably, triggering the pop-up opening)
  • the third targets content of the pop-up window

So far, not seeing anything out of order.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #24)

Happy to try debugging this locally as well with a few pointers too.

Since the issue is a pop-up closing when we don't expect it to: perhaps we can put a breakpoint in a place associated with the popup closing (some kind of "Rollup" function / event maybe?), and see what input event (or other kind of event) is triggering that?

Set release status flags based on info from the regressing bug 1493208

status-firefox94: --- → affected
status-firefox95: --- → affected
status-firefox96: --- → affected
status-firefox-esr91: --- → affected

I can try.

Flags: needinfo?(emilio)

So I guess here is where code diverges based on APZ...

I think I know what's going on..

Assignee: nobody → emilio
Flags: needinfo?(emilio)

Thank you Emilio! Great!

Status: NEW → ASSIGNED
Flags: needinfo?(hikezoe.birchill)
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8d091e07033c Fix a couple bugs in Windows rollup code. r=mhowell

https://hg.mozilla.org/mozilla-central/rev/8d091e07033c

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox96: fix-optional → fixed
Resolution: --- → FIXED
Target Milestone: --- → 96 Branch

Verified the fix on the latest Nightly (96.0a1/20211107123941) under Windows 10 x64.

Tested with uBlock Origin and Bitwarden extensions. The pop-up no longer closes when tapping any button from the pop-up and touch interactions continue to work for other GUI elements, confirming the fix.

Status: RESOLVED → VERIFIED
status-firefox96: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: