977668 - Firefox hangs on Facebook text entry when inline lookups pop up

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Kev Needham [:kev]]

Attachment: screencap of hang, with lookup box showing

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.

Comment 1

[alexander :surkov (:asurkov)]

it'd be good to help stack

Comment 2

[Marco Zehe (:MarcoZ)]

FWIW, cannot reproduce on Windows 7 SP1 64 bit with NVDA running.

Comment 3

[Jim Mathies [:jimm]]

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?

Comment 4

[Kev Needham [:kev]]

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.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

(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.

Comment 6

[Kev Needham [:kev]]

(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. :)

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Doh! OK thanks got the popup going. Haven't hung it yet... (forcing key repeat or not)

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

(and I have a11y activated)

Comment 9

[Kev Needham [:kev]]

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.

Comment 10

[Trevor Saunders (:tbsaunde)]

(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.

Comment 11

[alexander :surkov (:asurkov)]

(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?

Comment 12

[Trevor Saunders (:tbsaunde)]

(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.

Comment 13

[John Hesling [:John99] (NeedInfo me)]

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

Comment 14

[John Hesling [:John99] (NeedInfo me)]

Possibly someone could add a regressionwindow-wanted  keyword. I have already asked in the support thread whether anyone is able to run mozregression.

Comment 15

[Bill]

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.

Comment 16

[nur.zeug]

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

Comment 17

[Jan Mráz]

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...

Comment 18

[guigs [:guigs] PST (please needinfo me!)]

Hey has the code submitter beeh asked fore more info?

Comment 19

[guigs [:guigs] PST (please needinfo me!)]

or the previous?

Comment 20

[Steve Workman [:sworkman] (INACTIVE)]

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.

Comment 21

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 22

[Jonathan Wei [:jwei]]

Comment on attachment 8404089 [details] [diff] [review]
patch

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

Nice catch.

Comment 23

[Steve Workman [:sworkman] (INACTIVE)]

(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!

Comment 24

[David Bolter [:davidb] (NeedInfo me for attention)]

Yes excellent, let's get this landed and on branches.

Comment 27

[Bill]

I'm new to this so forgive me if I am asking a dumb question but when will this fix appear in Firefox?

Thanks!

Comment 28

[Robert Kaiser]

(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.

Comment 29

[alexander :surkov (:asurkov)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/449e2da18cde

Comment 30

[Sylvestre Ledru [:Sylvestre]]

Alexander, Once it is in m-c, could you fill an uplift request? We are going to take it for 29. Thanks

Comment 31

[Adam]

I'm having same issue.  Is there anything I can do to resolve this prior to waiting for next update?

Regards,
Adam

Comment 32

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 33

[Adam]

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

Comment 34

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/449e2da18cde

Comment 35

[Sylvestre Ledru [:Sylvestre]]

(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 36

[alexander :surkov (:asurkov)]

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

Comment 37

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/dff8b2f0d02a
https://hg.mozilla.org/releases/mozilla-beta/rev/109cc0131968

Comment 38

[Bogdan Maris, Desktop Test Engineering]

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/

Comment 39

[Jan Mráz]

(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.

Comment 40

[alexander :surkov (:asurkov)]

(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

Comment 41

[BugMagnet]

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 42

[Trevor Saunders (:tbsaunde)]

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?

Comment 43

[alexander :surkov (:asurkov)]

(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.

Comment 44

[Jon Frimann]

Attachment: Debug output from Firefox 28.0.

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.

Comment 45

[Jon Frimann]

Attachment: Second debug output of Firefox 28.0 crash.

Here is the second output of the Firefox 28.0 crash on Gentoo Linux.