Firefox hangs on Facebook text entry when inline lookups pop up

RESOLVED FIXED in Firefox 29

Status

()

defect
--
critical
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: kev, Assigned: surkov, NeedInfo)

Tracking

({crash, hang})

29 Branch
mozilla31
x86_64
Windows 8.1
Points:
---

Firefox Tracking Flags

(firefox28 wontfix, firefox29+ fixed, firefox30+ fixed, firefox31+ fixed)

Details

(Whiteboard: [qa-] , crash signature)

Attachments

(4 attachments)

This bug was filed from the Socorro interface and is 
report bp-7615fee7-b952-4686-9bac-98a662140227.
=============================================================

When entering text in an edit box on Facebook that does FB Object lookups as you type, holding down the arrow key to move the cursor forwards or back can hang Firefox on Facebook when Facebook pops up it's entity popup (see screenie). Firefox becomes unresponsive but does not crash, and continues to consume memory until you thump the process with task manager.

OS: Windows 8.1 64-bit w/touchscreen monitor

Steps to reproduce:
- Log into facebook
- Compose a status entry with a word that contains a string that will trigger an inline lookup (I have used "Heavy Rotation") and add a number of characters following that.
- hold the left or right arrow key down to force a key repeat over the end of the string that triggers the lookup (in this case, "Rota" for "Nino Rota" - see attached)
- Aurora will eventually hang. Start 5-6 characters away from the end of the lookup string.
it'd be good to help stack
FWIW, cannot reproduce on Windows 7 SP1 64 bit with NVDA running.
I can't seem to get facebook to do this object lookup thing. Do you know if this is a feature controlled by a pref somewhere?
I don't believe it's a pref. It's what you get when you start typing a person's name without the @ sign and it pops up a list of suggestions. If you type the first few characters of a person's name from your friend list, it should pop up.
(In reply to Kev Needham [:kev] from comment #4)
> I don't believe it's a pref. It's what you get when you start typing a
> person's name without the @ sign and it pops up a list of suggestions. If
> you type the first few characters of a person's name from your friend list,
> it should pop up.

Strange. That's not happening for me, at least this morning.
(In reply to David Bolter [:davidb] from comment #5)
> (In reply to Kev Needham [:kev] from comment #4)
> > I don't believe it's a pref. It's what you get when you start typing a
> > person's name without the @ sign and it pops up a list of suggestions. If
> > you type the first few characters of a person's name from your friend list,
> > it should pop up.
> 
> Strange. That's not happening for me, at least this morning.

Capitalization is important. :)
Doh! OK thanks got the popup going. Haven't hung it yet... (forcing key repeat or not)
(and I have a11y activated)
I'll start looking to eliminate candidates like Setpoint, etc, too, and will create a fresh install of Win81 on another disk to see if new install with only fx and system drivers is affected.
(In reply to alexander :surkov from comment #1)
> it'd be good to help stack

huh? I"m seeing one lok under thread 0 you'll see its in HyperTextAccessible::TextBounds() called from some windows event dispatch code.
(In reply to Trevor Saunders (:tbsaunde) from comment #10)
> (In reply to alexander :surkov from comment #1)
> > it'd be good to help stack
> 
> huh? I"m seeing one lok under thread 0 you'll see its in
> HyperTextAccessible::TextBounds() called from some windows event dispatch
> code.

eventually I missed it. Does the stack says you something useful?
(In reply to alexander :surkov from comment #11)
> (In reply to Trevor Saunders (:tbsaunde) from comment #10)
> > (In reply to alexander :surkov from comment #1)
> > > it'd be good to help stack
> > 
> > huh? I"m seeing one lok under thread 0 you'll see its in
> > HyperTextAccessible::TextBounds() called from some windows event dispatch
> > code.
> 
> eventually I missed it. Does the stack says you something useful?

not really at a first look it seems like the one loop in that function shouldn't be able to iloop, but maybe its just really slow or maybe I miss something.
Note 

Apparently duplicates of this are Bug 990995 and  Bug 989789

There are probably several related threads ion the Mozilla "Sumo" support forum one such thread is 
Firefox 28 stops responding at Facebook dynamic search
https://support.mozilla.org/en-US/questions/991572
Possibly someone could add a regressionwindow-wanted  keyword. I have already asked in the support thread whether anyone is able to run mozregression.
I have this same problem with the current version of Firefox on Windows 7 64 bit.
It does not happen all the time. When it does happen I am not using arrow keys. I am just typing something that triggers the pop up box and a few entries appear and the Firefox is locked up. I can't go to other tabs. I can close Firefox with the window close x and it says it isn't responding. If I say kill it it goes away and then when I restart it restores all windows. 

And the problem started the morning that Firefox updated.

Also. If I type something like xx in the box and put the cursor directly to the left of the xx then this won't happen.
Same problem here.

Windbg might help because it seems to create an environment where I can´t reproduce this bug...

https://bugzilla.mozilla.org/show_bug.cgi?id=991519
Whenever I use Facebook dynamic search, Firefox stops responding. This issue also involves writing a new post/comment using the at-sign, which starts dynamic user search. I got Firefox not responding even at going through conversations (messages). So I can generalize that any operation at Facebook, during which three "waiting" bars appear, can lead to the not-responding state of Firefox.

   - Before update from Fx27 to Fx28 it did not happen. (I use Windows 7.)
   - Safe mode does not help.
   - Clearing cache and deleting Facebook cookies does not help. Neither new profile nor clean install helps.
   - There are no crash reports within Firefox as well as no Windows error logs generated.
   - Other browsers on this computer do not have this problem, another computer with Fx28 that I use works well. Firefox 28 on this computer with Ubuntu Linux works.

Based on mozregression it seems there are two breakpoints between three stages: 1. Firefox works. 2. Firefox crashes. 3. Firefox is not responding.

All those steps are bound to Firefox 28 nightly. It seems there had been a problem with crashes, which was identified, but the solution was only partial and led to the instability (not-responding behaviour of the official release).

The breakpoint between stages 1 and 2: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=50dcaa9d8d1a&tochange=dd984f4c205f

The breakpoint between stages 2 and 3: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bed37a1c69a5&tochange=87468d6fc936

The issue does not seem to be anyhow specifically connected to some hardware or an internet connection. I ran Firefox 28 on Ubuntu Linux with the same computer and the same internet connection without any problems. Nevertheless, there might be some OS specific (Windows) or driver specific behaviour, which has not been excluded by this investigation.

The regression showed problems introduced during the alpha stage of development connected with NS prefetching improvement, which took shape by Firefox crashes (bug 945308, solved). The remaining question is whether

   - the "not-responding" behaviour was introduced by the patch, or
   - emerged sometimes between "crashing" bug and its solution (and was covered by crashing), or
   - is an unresolved relic of the "crashing" bug...
Hey has the code submitter beeh asked fore more info?
Flags: needinfo?(surkov.alexander)
or the previous?
Flags: needinfo?(surkov.alexander) → needinfo?(sworkman)
Thanks for the information everyone. I see mention of a stack in comment 10. Could that or another stack trace be posted here please?

That said, however, based on the behavior here and the crash identified in bug 945308, I think it is better to start there.
Flags: needinfo?(sworkman) → needinfo?(surkov.alexander)
Posted patch patchSplinter Review
Attachment #8404089 - Flags: review?(jwei)
Flags: needinfo?(surkov.alexander)
Comment on attachment 8404089 [details] [diff] [review]
patch

Review of attachment 8404089 [details] [diff] [review]:
-----------------------------------------------------------------

Nice catch.
Attachment #8404089 - Flags: review?(jwei) → review+
(In reply to Jonathan Wei [:jwei] from comment #22)
> Comment on attachment 8404089 [details] [diff] [review]
> patch
> 
> Review of attachment 8404089 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Nice catch.

Indeed. Good job!
Yes excellent, let's get this landed and on branches.
I'm new to this so forgive me if I am asking a dumb question but when will this fix appear in Firefox?

Thanks!
(In reply to Bill from comment #27)
> I'm new to this so forgive me if I am asking a dumb question but when will
> this fix appear in Firefox?

That's still to be determined, but I think we should try and get it into 29, which ships in 3 weeks.


Given that Facebook is quite high-profile and this sounds like a major usability issue there, I'm nominating this for 29 and up.
Assignee: nobody → surkov.alexander
Alexander, Once it is in m-c, could you fill an uplift request? We are going to take it for 29. Thanks
Flags: needinfo?(surkov.alexander)
I'm having same issue.  Is there anything I can do to resolve this prior to waiting for next update?

Regards,
Adam
Adam, next Tuesday, if everything goes well, you should be able to download 29 beta 8 which should contain the fix. Otherwise, nightly should have it tomorrow.
Thanks for reply :)

I have gone back to 27 for now which has resolved issue but will upgrade to 28 beta 8 or wait for 29.

Regards,
Adam
https://hg.mozilla.org/mozilla-central/rev/449e2da18cde
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 31
Component: General → Disability Access APIs
Product: Firefox → Core
Target Milestone: Firefox 31 → ---
Target Milestone: --- → mozilla31
Severity: major → critical
Keywords: hang
(In reply to Adam from comment #33)
> I have gone back to 27 for now which has resolved issue but will upgrade to
> 28 beta 8 or wait for 29.
29 beta 8 ;)
Comment on attachment 8404089 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 945308
User impact if declined: hang
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): no risk (trivial fix)
String or IDL/UUID changes made by this patch: no
Attachment #8404089 - Flags: approval-mozilla-beta?
Attachment #8404089 - Flags: approval-mozilla-aurora?
Flags: needinfo?(surkov.alexander)
Attachment #8404089 - Flags: approval-mozilla-beta?
Attachment #8404089 - Flags: approval-mozilla-beta+
Attachment #8404089 - Flags: approval-mozilla-aurora?
Attachment #8404089 - Flags: approval-mozilla-aurora+
Keywords: checkin-needed
Keywords: verifyme
I tried to reproduce the initial issue on old Nightly using a Surface Pro 2 - Windows 8.1 64bit and Dell XPS12 - Windows 8 64bit but with no success. 
Adam can you check if this is fixed on Firefox 29 beta 8, Nightly and Aurora?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/29.0b8-candidates/build1/win32/en-US/
http://www.mozilla.org/en-US/firefox/aurora/
http://nightly.mozilla.org/
Flags: needinfo?(adambentley1983)
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #38)
> I tried to reproduce the initial issue on old Nightly using a Surface Pro 2
> - Windows 8.1 64bit and Dell XPS12 - Windows 8 64bit but with no success. 
> Adam can you check if this is fixed on Firefox 29 beta 8, Nightly and Aurora?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/29.0b8-candidates/
> build1/win32/en-US/
> http://www.mozilla.org/en-US/firefox/aurora/
> http://nightly.mozilla.org/

(Even if I am not Adam,) I can confirm that the fix in Beta candidate and Nightly works - it no more freezes on 64bit Windows 7.

It is perhaps a question for Alexander what exactly was the issue and why only particular users are concerned.
Flags: needinfo?(surkov.alexander)
(In reply to Jan Mráz from comment #39)

> It is perhaps a question for Alexander what exactly was the issue and why
> only particular users are concerned.

I never tried to reproduce the issue, just fixed wrong code
Flags: needinfo?(surkov.alexander)
I just filed (996428) what appears to be yet another duplicate of this bug. I searched but apparently didn't use the proper terms to find this report. Mine was closed as a duplicate with a note that 991519 is similar.

I just migrated from XP to a new WIN7 x64 computer. (3 GHz AMD, 4 core CPU - 8GB RAM)

This issue has been a bane since. With XP I often had crashes when writing a comment on FaceBook.

But with Win7, it doesn't crash and burn. It freezes.

I run taskinfo and after these free-ups (it has happened to me 2 or 3 times in the last couple days) it shows FF using 25% CPU resources while in this state, until I 'terminated' it.

Taskinfo is capable providing output of details processes and threads. I captured that as text files. Taskinfo also performs process dumps. In this case, the main firefox dump was 1.3GB and a second item (child?) produced a dump of 117 MB.

If such information can be used to verify the cause of this, please let me know the best way to forward these files. (2 txt and 2 .dmp from an incident within the last 2 hours.)

I'd be installing 29b8 to stress-test this fix.
Comment on attachment 8404089 [details] [diff] [review]
patch

>   while (childIdx < ChildCount()) {
>-    nsIFrame* frame = GetChildAt(childIdx)->GetFrame();
>+    nsIFrame* frame = GetChildAt(childIdx++)->GetFrame();

standard grumble about x++ not being its own statement.

>     if (!frame) {
>       NS_NOTREACHED("No frame for a child!");
>       continue;
>     }

so, either there's no bug here or we have a test case for that assertion failing.  Have you debugged why it fails? is something actually wrong or is the assert wrong?

btw some reason you can't add test for this?
Keywords: verifyme
(In reply to Trevor Saunders (:tbsaunde) from comment #42)

> so, either there's no bug here or we have a test case for that assertion
> failing.

agree it'd be great to have a test case and debug it.
I am using Gentoo Linux 64bit and I am also seeing this bug. I re-compiled Firefox 28.0 with the debug symbols and made the crash happen. I have attached what I got into two text files.
Here is the second output of the Firefox 28.0 crash on Gentoo Linux.
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.