Closed Bug 477101 Opened 16 years ago Closed 16 years ago

Stuck in GMail after clicking "Show search options" or "Create a filter"

Categories

(Core :: JavaScript Engine, defect, P2)

Product:
Core
Component:
JavaScript Engine
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.2a1

People

(Reporter: ria.klaassen, Assigned: graydon)

References

(
URL
)

Details

(Keywords: regression, verified1.9.1)

STR: - Log in to your GMail account and go to your Inbox - Click on "Show search options" or "Create a filter" on top - Click on Trash, Drafts, Sent Mail or whatever on the left side - Note that GMail still displays the bar "Search Options" or "Create a filter" on top and can't go to the intended box anymore. This seems to have regressed on 27 Jan 2009: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8caadf42408c&tochange=f3a04709f5ac I checked the latest TM but was still able to reproduce it.
Not reproducible in Shiretoko so far.
Verified in Minefield
Verified today in Shiretoko on OS X, but I had missed a day or two of updates.
Comment 2 and comment 3 use "verified" to mean "confirmed", I think. If this bug is in m-c and tm then it may end up in 1.9.1 when a blocking or wanted fix is merged there -- so we should bisect or otherwise find it, ideally in the tracemonkey repo, sooner. /be
Flags: blocking1.9.1?
Sometimes I think I can't reproduce it anymore. But as soon as I test it with a new profile, I see it again.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
I need a testcase to reproduce this.
Really annoying, for the reproducibility has changed. The bug is still there, just tested with the very latest hourly, but more inconsistent to reproduce. On Vista I see it not as often anymore as on XP.
Sometimes when I click on a mail in my Inbox, I see the "Loading.." message appear on top, but after that Firefox gets stuck. I can't open the mail, I can't click on other links either. The only thing I can do is open another GMail in a new tab (or reload the page). After a few moments, when I switch back to the first GMail tab the header message has changed to "Still working..."
I can reproduce this 100% when clicking on a Gmail message from the iGoogle Gmail module (make sure it's the new version. Sandbox? With the side tabs) The loading bar goes to the end and then nothing else happens. Can anyone who uses igoogle enable the mail module and verify this?
I can reproduce this on the latest Minefield nightly build. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090223 Minefield/3.2a1pre turn off jit, and the bug is not reproducible. i'm in MV this week, let me know if you want to take a look.
switching OS to all, since i'm seeing this on Mac.
OS: Windows XP → All
I am out of the office tomorrow but we could get together Wednesday and debug this.
If reference to Comment #9, Gmail fails to load whether JIT is enabled or disabled I also forgot to mention that in the Gmail iGoogle gadget, you need to set it to open mail in Gmail, not in the gadget
Assignee: general → graydon
(In reply to comment #9) > I can reproduce this 100% when clicking on a Gmail message from the iGoogle > Gmail module (make sure it's the new version. Sandbox? With the side tabs) The > loading bar goes to the end and then nothing else happens. > > Can anyone who uses igoogle enable the mail module and verify this? This is a different bug (also looks quite different). Is much more recent, something from 16 Feb.
Can reproduce the bug in question (not the igoogle sub-issues) using STR in original report, linux, tracemonkey tip, today, revision 42acafcdae02.
Some notes, gotta step out for a bit: I ran this under "live http headers" and the action in question provokes a unique sort of response to gmail when the JIT is turned on (no such response when the JIT is turned off). It looks like they trap their own errors and POST them back to themselves for diagnostics. So if you URL-decode the unique POST request here, it actually contains a JS backtrace. Claims to be throwing an error of type ".68" (obfuscated). Top few frames of the backtrace look like this: $fm("y",-1,false)@https://mail.google.com/mail/?ui=2&view=js&name=js&ver=oOe_Fx-LJvQ&am=X7UYJcT3cLmJBfni0fB3lVhdXw:410 $xn("y",-1,[object Object])@https://mail.google.com/mail/?ui=2&view=js&name=js&ver=oOe_Fx-LJvQ&am=X7UYJcT3cLmJBfni0fB3lVhdXw:430 $6y("y",-1,[object Object])@https://mail.google.com/mail/?ui=2&view=js&name=js&ver=oOe_Fx-LJvQ&am=X7UYJcT3cLmJBfni0fB3lVhdXw:605 $un("y",-1,false)@https://mail.google.com/mail/?ui=2&view=js&name=js&ver=oOe_Fx-LJvQ&am=X7UYJcT3cLmJBfni0fB3lVhdXw:430 $fm("y",-1,false)@https://mail.google.com/mail/?ui=2&view=js&name=js&ver=oOe_Fx-LJvQ&am=X7UYJcT3cLmJBfni0fB3lVhdXw:410 $xn("y",-1,[object Object])@https://mail.google.com/mail/?ui=2&view=js&name=js&ver=oOe_Fx-LJvQ&am=X7UYJcT3cLmJBfni0fB3lVhdXw:430 $un("y",-1,false)@https://mail.google.com/mail/?ui=2&view=js&name=js&ver=oOe_Fx-LJvQ&am=X7UYJcT3cLmJBfni0fB3lVhdXw:430 $fm("y",-1,false)@https://mail.google.com/mail/?ui=2&view=js&name=js&ver=oOe_Fx-LJvQ&am=X7UYJcT3cLmJBfni0fB3lVhdXw:410 ... I fetched the JS in question and pulled out the functions with those names on those lines: // line 410's $fm function is: function $fm(a,b,c){ this.b(); var e=this.ng, f=!!c; this.v4a(a); if(e) if(!(!this.on() && b==this.Qv(a) &&f==this.iGc(a))) { if(this.Wz(a)!=-1&&b==-1) throw t(".68"); // our error originates here this.He(a,b,f) } this.DSa(a) } // line 430's $xn function is: function $xn(a,b,c){ var e=this.Qg(); if(!!e){ var f=0; for(;f<e;f++){ var g=this.uc(f), h=c[g.ka()]; g.Sy(a,h,this.WVb==zp&&a==Ss&&h==b) } } } // line 605's $6y function is: function $6y(a,b,c){ var e=this.Qg(); if(!!e){ if(a==Ss){ var f=0,g=0; for(;g<e;g++){ var h=this.uc(g); f+=c[h.ka()] } var l=f<=b?-1:f; if(this.cbb!=l){ this.cbb=l; ia(this.bC,Oo(l)) } } Rs.C.gN[j](this,a,b,c) } } // line 430's $un function is: function $un(a,b,c){ this.DI(a,b,c); this.G3(a,b); this.gN(a,b,Qo[a]) } I'll dig further later, that's all I've got so far...
The gadget issue filed as bug 480050.
Depends on: 480050
No longer depends on: 480050
I think I can reproduce this gmail lockup 100% of the time, if I: 1. Either check the box next to any message and then click "Filter messages like these" from the "More actions" drop menu (or click the same things with an email message open) 2. Change the text in the "From:" text field. 3. Now click the "test search" or "next step" button, and both of those buttons will gray out. This also appears to happen if I click any link from "Inbox" to "Trash" on the left side panel. *** The key to reproducing this 100% for me is changing the text in the "From:" text field.
(In reply to comment #19) I forgot to mention: I'm using "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2a1pre) Gecko/20090227 Minefield/3.2a1pre" With Windows XP x64
I have the same problem.
Further isolation via code inspection was proving ... challenging. Took different tack for a while and bisected / manually searched in to the first place it's detectable. Unfortunately (a) there's a confounding error, such that you have to apply a back-port of revision e6c5ad00591d to even get it to work without crashing, which kills automatic bisecting quite a ways out, and (b) the actual isolated rev at which gmail starts misbehaving is revision 47a266935e7d, which is not terribly helpful. The guilty revision is one of mine, but it's the one in which I reorganized the fragment hit counts and blacklist marks to live in the oracle. This area has been subject to further work since, yet the error persists: I expect all that happened is 47a266935e7d *uncovered* a previously-latent bug due to fiddling the blacklisting / hit-counting machinery; in particular running it through a hash function. Whether this is true remains to be seen. It's not clear to me how to proceed, either way. I'll poke around a few other angles to see if there's an overlooked flaw in the hit counting system, now that I have something to examine the "difference" of before-and-after the exposure of buggy behavior. Just thought I'd add a note here on "progress".
Curiously, this bug appears to have been fixed by 1http://hg.mozilla.org/tracemonkey/rev/1852d9fe853d It is not clear to me why, exactly. I'll dig a bit more shortly.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
sayer, i assume you didn't mean to set this bug resolved/fixed , right ?
oops, my bad
I still see this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090312 Shiretoko/3.1b4pre ID:20090312054420
Comment #23 refers to a checkin on the Tracemonkey branch. Did it land on 1.9.1 as well?
How does it correlate to bug 478778? I believe both bugs are caused by the same underlying problem. Luke, which error pops-up in the error console? Something with $root...?
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
Sorry, both bugs are not related. This one doesn't throw any error. I can verify that it is fixed on trunk with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090313 Minefield/3.2a1pre ID:20090313031058 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090311 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090311051703
Status: RESOLVED → VERIFIED
Flags: in-testsuite-
(In reply to comment #28) > Luke, which error pops-up in the error console? Something with $root...? The only error I get is : Error: .50 Source File: https://mail.google.com/mail/?ui=2&view=js&name=js&ver=HASWGW5R8Jg.en_GB.O&am=V_m4p8L3cOGABb3i0_R3Egy_0CE Line: 413 This error is generated 80% of the time by clicking 'Show search options...' and then immediately clicking cancel, Gmail gets stuck. This is with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090315 Shiretoko/3.1b4pre ID:20090315052502 Hopefully this will be fixed in the next TM merge with branch.
FYI, at the moment I can reproduce a similar issue but also with JIT disabled (so not related to this bug), and this is probably due to Bug 483751.
This bug is still there, or at least what was reported on bug 480326, which was set as a duplicate of this one. I can link this to a crash happening shortly after I reproduce this bug with the filters option. Can someone reopen this? Or should bug 480326 be set as not a duplicate of this one?
I filed Bug 483751 and marked it a duplicate of this one. Both are now fixed on the trunk (minefield). The patch TM is waiting to land on 3.5 shiretoko branch, so if you are using beta 3 this is not fixed. AFAIK neither bug ever resulted in a full crash of the browser. If you are seeing a full browser crash it is likely a different bug.
Has this patch made it over to the 1.9.1 branch?
(In reply to comment #36) > Has this patch made it over to the 1.9.1 branch? Yes, branch doesn't get stuck on creating filters.
needs to be verified1.9.1.
Keywords: fixed1.9.1
verified in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090521 Shiretoko/3.5pre
Verified too on OS X and Linux with builds like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090524 Shiretoko/3.5pre ID:20090524031149 Does it mean we can remove relnote now?
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.