Closed Bug 430021 Opened 16 years ago Closed 15 years ago

gmail ends up with infinite loop with latest firefox

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: fecakovacs, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

After updating newest release cannot login to gmail, it ends up to an infinite loop loading inbox, in the loading sometimes even google.com appears. Interesting part is that if I directly go into a mail from Gtalk account it can handle it. This happens to my friends also and only on Firefox, both on Windows and Linux too.


Reproducible: Always

Steps to Reproduce:
1. Enter gmail.com, sometimes it starts looping here
2. If not, try to login, it definetely starts looping here
Have exact same problem on Mac running OS X v10.5.2 since installing Firefox 2.0.0.14.  I can get to my gmail messages through Apple "Mail" utility, but not using Firefox.
There is a workaround for this, delete all cookies with Tools/Clear private data. However I dont think an everyday user will find this out on his/her own, this should be fixed.
Unfortunately I just tried on other machines, it does not always solve the problem :(.
Thanks Ferenc! That fixed it for me.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
For people who can reliably reproduce this in 2.0.0.14, does 2.0.0.13 work? Searching around the web in general, there are comments suggesting that a bunch people started having this problem at about the same time even without having upgraded their browsers.
For me it did not occur to 2.0.0.13 but it may be possible gmail changed something. Anyway it works with other browsers. Also a possible workaround BTW is when it is in an infinite loop just pushing F5 (refresh) then it works.
(In reply to comment #8)
> For me it did not occur to 2.0.0.13

My question isn't whether it used to happen with 2.0.0.13, but whether or not people currently seeing this behavior in 2.0.0.14 can reproduce it *now* in 2.0.0.13 on the same machine.
Looks like it depends on the profile. I see the looping Gmail loading since 3.0b3 and now with a parallel installed 2.0.0.13 as well. But it not happens with a new profile/user on both 2.0.0.13 and 3.0b5.
If it happens now with 2.0.0.13, then it's almost certainly a server issue that happened to coincide with the 2.0.0.14 release. This should probably be closed INVALID, but I'll leave that for a Firefox triager to decide.
But what about the background running Firefox problem. Nearly everytime Firefox takes 100% CPU on looping with Gmail and runs further in background when closed with File -> Quit. This happens the first time with 3.0b3. Not sure if it happens also with 2.0.0.13. Interestingly the process viewer says half of the CPU time of Firefox running in the background is Kernel time. Linux Kernel 2.6.23.

Also Gmail loads everytime in no time if Firefox is restartet. I always quit Firefox with the looping Gmail running, kill the background process and restart. Then Gmail loads at once when FF rebuilds the last open windows and tabs.  
I'm also seeing this with SeaMonkey 1.1.9 on Linux (the Firefox 2.0.0.13 counterpart, rv:1.8.1.13), but to a lesser extent. Usually on the first login, or when returning after some time, I get a one-time looping with brief pop-up of the Google search bar, then getting back to "Loading...". Overall, it appears that loading the Inbox page coming from a different web page takes longer than before (maybe looping multiple times without the bar appearing).

I haven't seen this behavior upon initial upgrade to SM 1.1.9, it showed up later, possibly (not sure) coinciding with FF 2.0.0.14 release. I do *not* see it with FF 2.0.0.14 on Windows XP, or in nightly trunk builds on the same Windows machine, thus it's quite puzzling under which conditions this problem shows up. Cookie-behavior (allow session cookies) is identical on all versions, thus they start up with cleared cookies.

(In reply to comment #11)
> If it happens now with 2.0.0.13, then it's almost certainly a server issue that
> happened to coincide with the 2.0.0.14 release.

It equally well may be a combination of changes in the Gmail server with some dormant issue in Gecko-based browsers which got only triggered after those changes were made on the server side. Thus, the criteria probably should be if this is also observed with other (non-Gecko) browsers as well.
Follow-up to my previous comment: On the same Linux machine where I see the occasional but finite looping with SM 1.1.9, I don't see it with FF 2.0.0.10 despite several open/close/get-back attempts. As for other browsers, I also don't observe it with Konqueror 3.4.2 (which is partially supported only by the Gmail site, though). Running a 2.6.13 kernel (comment #12).

(In reply to comment #10)
> Looks like it depends on the profile. I see the looping Gmail loading since
> 3.0b3 and now with a parallel installed 2.0.0.13 as well. But it not happens
> with a new profile/user on both 2.0.0.13 and 3.0b5.

This would be supported by my observations. While the SeaMonkey profile is in daily use, the Firefox profile was a fairly recent, rarely used one. If it depends on the profile, it's unlikely to be a Gmail-server issue alone.
OS: Windows XP → All
Hardware: PC → All
Update: The last days Gmail loads fine within seconds without looping.
Didn't see any looping either for a week or so. Also, the login now shows a progress bar, thus Gmail changed something in their servers. If it indeed was some interoperability issue, it seems to be no longer reproducible.
Looping is here again since three days or so. With 3b5 and 3rc1.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Ferenc, why did you close this bug? According to comment #17, the issue persists at least in one case. Also, this can't be resolved as FIXED without a bug actually being fixed. It would either be WORKSFORME if it's not reproducible and the cause unknown, or INVALID if it's conclusively a Gmail problem only, the basis of which I don't see given for either of those.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Seeing some looping again today and yesterday (SM 1.1.9 with 1.8.1.14 patches, Linux). The progress bar starts to "load", then disappears and starts over again, then the Inbox appears. This still remains a rather random problem then.
This is Google's recommendation, referred to in the MZ forum thread mentioned
in bug 432837 comment #1 - "Some users have reported that Firefox continually refreshes as Gmail loads. If you're experiencing these infinite browser redirects, sign in from our secure site at https://mail.google.com/mail ."

http://mail.google.com/support/bin/static.py?page=known_issues.cs
Signing at https://mail.google.com/mail works for me with FF 3.0rc2. No redirects/looping anymore.
(In reply to comment #22)
> Signing at https://mail.google.com/mail works for me with FF 3.0rc2. No
> redirects/looping anymore.
> 

That worked the first time I tried it, but now it doesn't always work for me, either, and continues to cycle through and not load for 30 seconds or so.  It finally does load, but it still doesn't seem to be working right.
http://mail.google.com/mail (without encryption) also works here again since a week or so.
Both at home (WinXP) and at my office (Win2k) I had this loop for Seamonkey 1.1.11 and 1.1.10 (and maybe 1.1.9) for the url http://gmail.com.
The progress bar starts again several times per second.
Also the url http://mail.google.com/mail gives this result. I searched for any gmail cookie in the cookie list and the blocking list, but I couldn't find any.

Now I tried https://mail.google.com/mail (note: http*s*) and at the office this gave a pop-up with the following text:
------------------
Redirect Loop
Redirection limit for this URL exceeded.  Unable to load the requested page.  This may be caused by cookies that are blocked.
The browser has stopped trying to retrieve the requested item. The site is redirecting the request in a way that will never complete.

    * Have you disabled or blocked cookies required by this site?
    * NOTE: If accepting the site's cookies does not resolve the problem, it is likely a server configuration issue and not your computer.
-------------------

At that moment I allowed cookies for that site and the page did load!
Then I tried again http://mail.google.com/mail (note: http) and this now works also as does http://gmail.com.

Any Firefox installation at the office did ever show this loop.
I have an infinite loop loading google DOCS as httpS://docs.google.com
Started at firefox 3.
Also happens if I click from gmail (logged in securely) to documents.
See bug 449589 for a similar report on Google calendar.
Can this be considered resolved if that's no longer an issue for anybody?
Personally, I didn't see any looping for considerable time now.
Yes
Yes (FF3.0 and FF3.1bx are okay)
Yes for me too
No more reports, closing this now. Feel free to reopen if the issue returns.
-> WFM
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago15 years ago
Resolution: --- → WORKSFORME
thanx to rsx11m, my problem is solved after extensive study of these comments, specifically comment #25.  But my observation is that this really points to a customer service issue I detail in bug 491175.

Though this bug is marked as "works for me," someone take this to the next step or show me the way.
thanx to rsx11m, my problem is solved after extensive study of these comments, specifically comment #25.  But my observation is that this really points to a customer service issue I detail in bug 491175.

Though this bug is marked as "works for me," someone take this to the next step or show me the way.
Blocks: 496588
Verifying Worksforme on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.