[e10s] parent process handles shortcuts and mouse events (e.g. contextmenu) in a wrong tab if I select another tab

NEW
Unassigned

Status

()

Firefox
Tabbed Browser
P2
normal
2 years ago
a year ago

People

(Reporter: arni2033, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(e10s+, firefox47 disabled, firefox48 affected, firefox49 affected, firefox50 affected, firefox51 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
not-entirely-accuratesee-comment-5
>>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160212030242
STR:
1. Open the following "data:" url in a new window. Close other tabs in that window
>   data:text/html,<a href="http://www.rp-online.de/">Link</a>
2. Middle-click that Link 5 times at the speed >= 1 middleclick per second
3. Close the tab with "data:" url. You'll get 5 tabs with the "heavy" site
4. Press Ctrl+M, then Ctrl+PageDown   (with minimal pause!)
5. If you still don't see the bug:   do {Ctrl+Shift+Tab, then Ctrl+Shift+R} 5 times, repeat Step 4

Note:
 If you have super-fast PC, try 10 tabs instead of 5 in STR.
 I usually have 40+ tabs opened, so I only need Step 4 to reproduce. Screencast is useless IMO.
Jeff, looking for a priority
tracking-e10s: --- → +
Flags: needinfo?(jgriffiths)
Flags: needinfo?(jgriffiths)
Priority: -- → P2
(Reporter)

Comment 2

2 years ago
Actually, a lot of hotkeys work the same way, including:
Ctrl+Shift+M, Ctrl+Shift+I, Ctrl+Shift+C, F12, Shift+F7, Shift+F5, etc.   STR are the same
In Step 4 you can click a tab instead of pressing Ctrl+PageDown/PageUp

All shortcuts looked _this_ broken all the time, and I just got time to check if this was true.
Sorry for NI again, but maybe now this is bigger priority?
status-firefox48: --- → affected
Flags: needinfo?(jgriffiths)
Summary: [e10s] Ctrl+M toggles sound indicator in a wrong tab if I immediately select another tab → [e10s] Ctrl+M and all devtools shortcuts take action in a wrong tab if I immediately select another tab
(In reply to arni2033 from comment #2)

> Sorry for NI again, but maybe now this is bigger priority?

Not with that complicated of an STR. If the bug manifested via a 'normal' user interaction sequence and speed, it would be higher.
Flags: needinfo?(jgriffiths)
(Reporter)

Comment 4

2 years ago
(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #3)
> Not with that complicated of an STR.
I don't see why you call pressing Ctrl+R, then switching a tab in 2 seconds a "complicated STR"

I always provide as reliable STR as possible so that everybody (even people with super-fast PCs) reproduced the bug. In real-life browsing you don't need much speed, because e10s just lags a_lot

New affected shortcuts: Ctrl+D, Ctrl+(Shift+)R.   Ctrl+W is unaffected.
Summary: [e10s] Ctrl+M and all devtools shortcuts take action in a wrong tab if I immediately select another tab → [e10s] almost all shortcuts take action in a wrong tab if I immediately select another tab
(Reporter)

Comment 5

2 years ago
str
Created attachment 8756784 [details]
screencast 1 - events from background tab take action in foreground tab.webm

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160522030240
STR_2:
1. Open new tab (I), open new tab with https://hg.mozilla.org/mozilla-central/rev/02ad58b18823 (II)
2. While (II) is still loading, switch to (I) and back ~2 times. It's good if you see the a spinner
   in the center of page (II). That's a clear indication that content process is not responding.
3. Click on the spinner
4. Right-click on the spinner several times (to be sure)   OR   press Ctrl+M
5. Click on the (I) to switch to that tab (make sure you understand STR correctly, i.e. content
   process in tab (II) is still lagging when you leave the tab)
6. Wait until (II) completely loads

AR:  Action (Step 4) from background tab (II) takes effect in tab (I)
ER:  Action (Step 4) should be applied to original tab (II). In the case of context menu,
     it should be hidden after 0ms (or don't even appear), because I switched between tabs.

Notes:
 Usually it happens with me on normal heavy pages like Youtube, that don't even show spinner.
 If there was a lot of time between Step 4 and Step 6, this bug doesn't happen, so on the video
 I used more lightweight page. You can use:   http://hg.mozilla.org/mozilla-central/rev/556628e979a3
(Reporter)

Updated

2 years ago
Component: Tabbed Browser → Event Handling
Product: Firefox → Core
Summary: [e10s] almost all shortcuts take action in a wrong tab if I immediately select another tab → [e10s] shortcuts and right-click for contextmenu take action in a wrong tab if I select another tab

Updated

2 years ago
Component: Event Handling → Tabbed Browser
Product: Core → Firefox

Comment 6

2 years ago
(This isn't a core issue but e10s UI not behaving correctly.)
(Reporter)

Updated

2 years ago
See Also: → bug 1248683
This is probably caused by TabParent changing the order of events, like bug 1218351 and discussed in bug 1248683.
Blocks: 516752
(Reporter)

Comment 8

2 years ago
This includes middle-click to start autoscrolling and Ctrl+Click to open link in a next tab
status-firefox47: affected → disabled
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
Summary: [e10s] shortcuts and right-click for contextmenu take action in a wrong tab if I select another tab → [e10s] parent process handles shortcuts and mouse events (e.g. contextmenu) in a wrong tab if I select another tab
(Reporter)

Updated

a year ago
Duplicate of this bug: 1292526
(Reporter)

Updated

a year ago
You need to log in before you can comment on or make changes to this bug.