Closed Bug 882918 Opened 11 years ago Closed 11 years ago

Defect - Pages/Chrome don't respond to events

Categories

(Firefox for Metro Graveyard :: Browser, defect, P2)

x86_64
Windows 8
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 931743

People

(Reporter: rnewman, Unassigned)

References

()

Details

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?
Official Nightly.
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect c=browsing u=metro_firefox_user p=0
Priority: -- → P2
(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?
(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: 11 years ago
Resolution: --- → WORKSFORME
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
Summary: Defect - Pages don't respond to events → Defect - Pages/Chrome don't respond to events
No longer depends on: 840855
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → DUPLICATE
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.