Defect - Pages/Chrome don't respond to events

RESOLVED DUPLICATE of bug 931743

Status

defect
P2
normal
RESOLVED DUPLICATE of bug 931743
6 years ago
6 years ago

People

(Reporter: rnewman, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

()

Reporter

Description

6 years ago
Open a pull request. Click "Files changed" to get a diff view.

Now try to do anything. Scroll with your finger, for example. Observe that the UI totally hangs; no finger scrolling, keyboard scrolling, selection, scrollbar action. If you're lucky, doing something like tapping with a stylus will unlock the UI for a few hundred milliseconds, giving it just enough time to jump to another part of the page.

This might just be a particularly bad version of the wider "if there's any JS in the page, Metro is almost unusably slow" issue; not sure.
Blocks: metrov1defect&change
No longer blocks: metrov1triage
Summary: GitHub patch view unusably slow → Defect - GitHub patch view unusably slow
Whiteboard: feature=defect c=tbd u=tbd p=0
Blocks: 887442
I think this is another manifestation of the bug where touch input sometimes stops working.
Was this using a release build or a debug build?
Reporter

Comment 4

6 years ago
Official Nightly.
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect c=browsing u=metro_firefox_user p=0
Priority: -- → P2
Reporter

Comment 5

6 years ago
(In reply to Brian R. Bondy [:bbondy] from comment #2)
> I think this is another manifestation of the bug where touch input sometimes
> stops working.

It seems that way; just hit the same behavior on <http://rideapart.com/2013/07/the-5-best-motorcycle-roads-in-america>, so it's not limited to GH.
Is this still happening on today's (or later) nightly?
Reporter

Comment 7

6 years ago
(In reply to Brian R. Bondy [:bbondy] from comment #6)
> Is this still happening on today's (or later) nightly?

Things seem to be *a lot* more responsive today. Can't conclusively verify (I'll keep my eyes open), but it seems to be resolved...

What was the cause, out of interest?
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Reporter

Comment 9

6 years ago
I just had essentially this exact experience with 07/23 Nightly on the Gmail 2-factor auth screen. Tapping, clicking, typing did nothing... until I hit the Windows button. As the app faded away (and the event loop cleared?), I saw the numbers I had typed appear in the box.

Reopening this rather than comment on a dead bug, but feel free to morph/dupe.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Defect - GitHub patch view unusably slow → Defect - Pages don't respond to events
I wonder if this is related to bug 840855 or perhaps bug 896896.

It's a little frightening how frequently we seem to be dropping input messages. Perhaps we should do some kind of audit of all of our Windows message-handling code in metro?
Whiteboard: feature=defect c=browsing u=metro_firefox_user p=0 → feature=defect c=browsing u=metro_firefox_user p=0 [preview]
Summary: Defect - Pages don't respond to events → [MP] Defect - Pages don't respond to events
Whiteboard: feature=defect c=browsing u=metro_firefox_user p=0 [preview] → [preview] feature=defect c=browsing u=metro_firefox_user p=0
Blocks: metrov1backlog
No longer blocks: metrov1defect&change
Depends on: 840855
No longer blocks: MetroPreviewRelease
Summary: [MP] Defect - Pages don't respond to events → Defect - Pages don't respond to events
Whiteboard: [preview] feature=defect c=browsing u=metro_firefox_user p=0 → feature=defect c=browsing u=metro_firefox_user p=0

Updated

6 years ago
Summary: Defect - Pages don't respond to events → Defect - Pages/Chrome don't respond to events

Updated

6 years ago
No longer depends on: 840855

Updated

6 years ago
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 931743
No longer blocks: metrov1backlog, 887442
Whiteboard: feature=defect c=browsing u=metro_firefox_user p=0
You need to log in before you can comment on or make changes to this bug.