back to google search results (and home) page displays blank page

RESOLVED DUPLICATE of bug 908446

Status

()

RESOLVED DUPLICATE of bug 908446
6 years ago
5 years ago

People

(Reporter: pf, Unassigned)

Tracking

24 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(12 attachments)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20130530 Firefox/24.0 (Nightly/Aurora)
Build ID: 20130530031141

Steps to reproduce:

1. google.com
2. search terms
3. google results page
4. follow a link
5. hit Back
6. blank page



Actual results:

When this problem triggers (VERY rare), Back to google results always displays a blank page. Reloading the blank page returns results and problem disappears, until next time...

Just had it happen again on 24.0a1 (2013-05-30) -- only on google search results page.

Happened on one tab.  Tried the same search and link follow on other new tabs without problem.  Yet, back to the tab with the issue and I could Forward/Back over and over, always getting a blank page where the google search results should be.  All the other tabs I opened trying to reproduce would not trigger the bug which stayed on the first tab until I reloaded it & cleared the bug...  Using the debugger, it appears FF is getting the google page contents; just not displaying it for some reason.  

UPDATE:  bug apparently reproducible on multiple tabs with these sequences:
1. New tab: google.com
2. search for "mantra"
3. follow Wikipedia link
4. Back -- blank page

1. New tab: google.com
2. search for "mantra"
3. follow thefreedictionary.com link
4. Back -- ok
5. follow Wikipedia link
6. Back -- blank page

On a used tab:
1. google.com
2. search for "mantra"
3. Follow Wikipedia link
4. Back -- blank page (should be search results)
5. Back -- blank page (should be google home page)
6. Back -- page which was on this tab comes back fine.

**flipping between the bad and other good tabs, the page content was almost identical -- differed in that the new ones contained some other search terms from previous searches; probably google tracking stuff.


Expected results:

Display results/home page, not blank.

[opening clean new bug report and closing bug 802292 which I've accidentally convoluted]
(Reporter)

Comment 1

6 years ago
Seems to be style sheet related...  when I do any google search, the results page gives 12 style sheets containing 426, 1130, 37, 68, 113, 4, 336, 3, 19, 0, 0, 40 rules respectively.  When I click Back after visiting a link, if the google results page is visible, the rules are the same.

In those cases where the page is blank (actually "hidden" -- see below) there are only 5 style sheets containing 426, 49, 37, 10, 0 rules respectively.

If I copy the URL of the search results page, and paste it into a new tab (bypassing the google.com home page), I can follow the link and Back works as expected.

AHA!!  Check the body tags -- something is adding "visibility: hidden;"...

When I get a blank page:

<body id="gsr" class="srp tbo" vlink="#61c" text="#222" link="#12c" bgcolor="#fff" alink="#dd4b39" onload="try{if(!google.j.b){document.f&&document.f.q.focus();document.gbqf&&document.gbqf.q.focus();}}catch(e){}if(document.images)new Image().src='/images/nav_logo123.png'" style="visibility: hidden;">

When it's OK, only 'class=' changes (2 examples):

<body id="gsr" class="vsh hp" vlink="#61c" text="#222" link="#12c" bgcolor="#fff" alink="#dd4b39" onload="try{if(!google.j.b){document.f&&document.f.q.focus();document.gbqf&&document.gbqf.q.focus();}}catch(e){}if(document.images)new Image().src='/images/nav_logo123.png'" style="">

body id="gsr" class="srp tbo vsh" vlink="#61c" text="#222" link="#12c" bgcolor="#fff" alink="#dd4b39" onload="try{if(!google.j.b){document.f&&document.f.q.focus();document.gbqf&&document.gbqf.q.focus();}}catch(e){}if(document.images)new Image().src='/images/nav_logo123.png'" style="">

etc...

Will add the full text of the pages.... 
[Collecting via Ctrl+U (*.Source) and right-click+Copy OuterHTML (*.OuterHTML)]

<SIGH> There may be a bug in the Debugger....  in trying to get the page sources of:
- google.com
- google results
- wikipedia.org
- google results (Back -> blank)
- google.com (Back to home -> blank)
I get this:
 $ ll /tmp/FF/*  (sorted to match above list, and lines numbered)
1  -rw-r--r-- 1 pfortin pfortin 117430 Jun  2 09:13 /tmp/FF/google.com.OuterHTML
2  -rw-r--r-- 1 pfortin pfortin 106539 Jun  2 09:12 /tmp/FF/google.com.Source
3  -rw-r--r-- 1 pfortin pfortin 294719 Jun  2 09:16 /tmp/FF/googleresults.OuterHTML
4  -rw-r--r-- 1 pfortin pfortin 106539 Jun  2 09:14 /tmp/FF/googleresults.Source
5  -rw-r--r-- 1 pfortin pfortin 365535 Jun  2 09:17 /tmp/FF/wikepedia.org.OuterHTML
6  -rw-r--r-- 1 pfortin pfortin 248380 Jun  2 09:17 /tmp/FF/wikipedia.org.Source
7  -rw-r--r-- 1 pfortin pfortin 110771 Jun  2 09:20 /tmp/FF/googleresults.blank.OuterHTML
8  -rw-r--r-- 1 pfortin pfortin 103551 Jun  2 09:19 /tmp/FF/googleresults.blank.Source
9  -rw-r--r-- 1 pfortin pfortin 110771 Jun  2 09:22 /tmp/FF/google.com.blank.OuterHTML
10 -rw-r--r-- 1 pfortin pfortin 103551 Jun  2 09:22 /tmp/FF/google.com.blank.Source

Note how 2=4, 7=9 and 8=10...

Adding them all anyway...
(Reporter)

Comment 2

6 years ago
Created attachment 757110 [details]
google.com source
(Reporter)

Comment 3

6 years ago
Created attachment 757111 [details]
google.com OuterHTML
(Reporter)

Comment 4

6 years ago
Created attachment 757112 [details]
google results Source
(Reporter)

Comment 5

6 years ago
Created attachment 757113 [details]
google results OuterHTML
(Reporter)

Comment 6

6 years ago
Created attachment 757114 [details]
wikipedia.org Source
(Reporter)

Comment 7

6 years ago
Created attachment 757115 [details]
wikipedia.org OuterHTML
(Reporter)

Comment 8

6 years ago
Created attachment 757116 [details]
googe results Back blank Source
(Reporter)

Comment 9

6 years ago
Created attachment 757117 [details]
googe results Back blank OuterHTML
(Reporter)

Comment 10

6 years ago
Created attachment 757118 [details]
google.com Back blank Source
(Reporter)

Comment 11

6 years ago
Created attachment 757119 [details]
google.com Back blank OuterHTML
(Reporter)

Comment 12

6 years ago
This bug is weirdly inconsistent...  at the moment, I have 3 tabs all reproducing the bug; but been trying to reproduce it on newer tabs to no avail...  

Time to grab the latest Nightly and try again...
(Reporter)

Comment 13

6 years ago
On 24.0a1 (2013-06-02), opened 7 tabs which all have the problem.  Reloaded 7th tab and it now works OK. Opened several other tabs which exhibit the same flaw.

Found this in about:config...
noscript.filterXExceptions set to
^https?://([a-z]+)\.google\.(?:[a-z]{1,3}\.)?[a-z]+/(?:search|custom|\1)\?^https?://([a-z]*)\.?search\.yahoo\.com/search(?:\?|/\1\b)^https?://[a-z]+\.wikipedia\.org/wiki/[^"<>\?%]+$^https?://translate\.google\.com/translate_t[^"'<>\?%]+$^https://secure\.wikimedia\.org/wikipedia/[a-z]+/wiki/[^"<>\?%]+$^https://payments\.namecheap\.com/

Cleared & restarting FF...
(Reporter)

Comment 14

6 years ago
No change after clearing noscript.filterXExceptions. Tried resetting it; now returns:
^https?://([a-z]+)\.google\.(?:[a-z]{1,3}\.)?[a-z]+/(?:search|custom|\1)\?
^https?://([a-z]*)\.?search\.yahoo\.com/search(?:\?|/\1\b)
^https?://[a-z]+\.wikipedia\.org/wiki/[^"<>\?%]+$
^https?://translate\.google\.com/translate_t[^"'<>\?%]+$
^https://secure\.wikimedia\.org/wikipedia/[a-z]+/wiki/[^"<>\?%]+$

but still no change to the issue.  Disabled NoScript -- still have the issue.

Disabled all add-ons/extensions -- still have this issue...
Component: Untriaged → Document Navigation
Product: Firefox → Core
Component: Document Navigation → Layout
Keywords: qawanted
(Reporter)

Comment 15

6 years ago
Created a new userid on my system and tried to reproduce this bug there...  no luck so far.  Of course, once a tab exhibiting the problem is reloaded, it doesn't reappear on that tab...   A quick test on my main userid shows that I get this bug every time using the above procedure...  willing to dig deeper; but need a new clue stick...  :)
(Reporter)

Comment 16

6 years ago
OUCH!!!   This bug is really twisted...  New way to get blank page:
1. new tab
2. google.com
3. enter "mantra" [1]
4. RELOAD search results page
5. BLANK page
6. reload page
7. search results back
At this point, no more blank pages on this tab. Totally reproducible here...

[1] replaced with "just a random search" and bug appears...
(Reporter)

Comment 17

6 years ago
Created attachment 757519 [details]
Console output

Turned on all Console logging. Got to blank page as in step 5 of comment 16 and copied messages to this attachment.  HTH
I'm really sorry, but I can't reproduce anything from comment 0, comment 16.
Tested on nightly 2013-06-03, Ubuntu 12.04 LTS x86_64.
What Linux distribution do you use ?
(Reporter)

Comment 19

6 years ago
As in comment 15, I can't reproduce either on a fresh userid.  Using Mageia2.

Are there any tools/utilities available for checking the contents of $HOME/.mozilla files?
What do you mean by "checking" ?
(Reporter)

Comment 21

6 years ago
Verifying the validity of the contents.  Or some way to compare /home/myuser/.mozilla/* against a fresh install in /home/test/.mozilla/*...  I've been searching for some tools -- found xmllint & jslint; but they don't help.  None of the *diff are useful unless I can find a tool to canonicalize the files.  eyeballdiff is just not up to the task...  :)
I'm not aware of that kind of tool. I'm using total commander to compare specific files by content.
But did you try with a new Firefox profile on the same user account ? 
http://support.mozilla.org/en-US/kb/Managing-profiles#w_starting-the-profile-manager
(Reporter)

Comment 23

6 years ago
Hopefully the profile stuff will help... here's what looks odd to me...

Can't reproduce yet on new profile.  However, just starting FF in the fresh account, then quitting without browsing, gave this:
nsStringStats
 => mAllocCount:         106344
 => mReallocCount:         5664
 => mFreeCount:          106052  --  LEAKED 292 !!!
 => mShareCount:         106451
 => mAdoptCount:           4991
 => mAdoptFreeCount:       4990  --  LEAKED 1 !!!


Trying again...  using my usual profile, I reproduced this bug using comment 16 steps 1-4; but forcing a prompt on konsole between each step as a delineation marker.  When I did the google page reload (giving a blank page), got this on the konsole as result of the reload:

JavaScript strict warning: chrome://browser/content/browser.js, line 10175: reference to undefined property aEvent.button
WARNING: NS_ENSURE_SUCCESS(rv, nullptr) failed with result 0x80570027: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/js/xpconnect/wrappers/WrapperFactory.cpp, line 300
++DOMWINDOW == 678 (0x7f87d7728cb0) [serial = 959] [outer = 0x7f87e0ee64b0]

#PF: Following 2 lines appeared 115 times.
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/dom/src/storage/DOMStorageManager.cpp, line 447
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/dom/base/nsGlobalWindow.cpp, line 9531

###!!! ASSERTION: Want to fire DOMNodeRemoved event, but it's not safe: '(aChild->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aChild)-> IsInNativeAnonymousSubtree()) || IsSafeToRunScript() || sDOMNodeRemovedSuppressCount', file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/content/base/src/nsContentUtils.cpp, line 3681



On the virgin account, while I can't reproduce the bug there, I get this on its konsole:

JavaScript strict warning: chrome://browser/content/browser.js, line 10175: reference to undefined property aEvent.button
JavaScript strict warning: chrome://browser/content/utilityOverlay.js, line 143: reference to undefined property e.button
WARNING: NS_ENSURE_SUCCESS(rv, nullptr) failed with result 0x80570027: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/js/xpconnect/wrappers/WrapperFactory.cpp, line 300
++DOMWINDOW == 17 (0x7f60e7835cb0) [serial = 25] [outer = 0x7f60ed23d4b0]

#PF: Following 2 lines appear 20 times.
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/dom/src/storage/DOMStorageManager.cpp, line 447
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/dom/base/nsGlobalWindow.cpp, line 9531

WARNING: Unable to locate an XBL binding for URI about:abp-elemhidehit?910856681367#dummy in document http://www.google.com/#gs_rn=16&gs_ri=psy-ab&suggest=p&cp=6&gs_id=eb&xhr=t&q=mantra&es_nrs=true&pf=p&output=search&sclient=psy-ab&oq=mantra&gs_l=&pbx=1&bav=on.2,or.r_qf.&bvm=bv.47534661,d.dmg&fp=5262ac682f5c3bff&biw=1398&bih=690: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/content/xbl/src/nsXBLService.cpp, line 734
###!!! ASSERTION: Why did this not get handled while processing mRestyleRoots?: '!element->HasFlag(collector->tracker->RootBit()) || (element->GetFlattenedTreeParent() && (!element->GetFlattenedTreeParent()->GetPrimaryFrame()|| element->GetFlattenedTreeParent()->GetPrimaryFrame()->IsLeaf())) || (aData.mChangeHint & nsChangeHint_ReconstructFrame)', file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/layout/base/RestyleTracker.cpp, line 88
WARNING: Unable to locate an XBL binding for URI about:abp-elemhidehit?910856681367#dummy in document http://www.google.com/#gs_rn=16&gs_ri=psy-ab&suggest=p&cp=6&gs_id=eb&xhr=t&q=mantra&es_nrs=true&pf=p&output=search&sclient=psy-ab&oq=mantra&gs_l=&pbx=1&bav=on.2,or.r_qf.&bvm=bv.47534661,d.dmg&fp=5262ac682f5c3bff&biw=1398&bih=690: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/content/xbl/src/nsXBLService.cpp, line 734
WARNING: NS_ENSURE_TRUE(selection->GetRangeCount()) failed: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/editor/libeditor/base/nsEditor.cpp, line 3833
WARNING: NS_ENSURE_SUCCESS(res, res) failed with result 0x80004005: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/editor/libeditor/text/nsTextEditRules.cpp, line 417

#PF: Following 2 lines appear 12 times.
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/dom/src/storage/DOMStorageManager.cpp, line 447
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/dom/base/nsGlobalWindow.cpp, line 9531




And closing my regular FF just gave this:
nsStringStats
 => mAllocCount:         995673
 => mReallocCount:        45358
 => mFreeCount:          990060  --  LEAKED 5613 !!!
 => mShareCount:        3315855
 => mAdoptCount:          56943
 => mAdoptFreeCount:      56931  --  LEAKED 12 !!!
(Reporter)

Comment 24

6 years ago
Paul, HELP!  After using -P to setup a second profile, I'm getting TONS of WARNING and other messages.  This is slowing things down quite a bit...  tried deleting the 2nd profile, copied a previous profiles.ini over to no avail...  Also getting "Bell in session 'shell'" popups from my window manager -- thankfully, that's not coming out as audio... however, they are stacking up because they can't keep up...

As I write this, konsole flooded with (about 10 per second):
###!!! ASSERTION: bad aListVisibleBounds: 'r.GetBounds().IsEqualInterior(aListVisibleBounds)', file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/layout/base/nsDisplayList.cpp, line 1009

How do I stop all this output???
Boris, can you please take a look ?
Pierre, it looks like you're using a debug build, hence all sorts of debug output.  Do you mean to be doing that?
(Reporter)

Comment 27

6 years ago
[orthogonal issue]
Only if Nightly is a debug build by default...  it's what I've been using for a LONG time...  never saw where there was a choice.  A few debug messages was the norm; but they came flooding out after using "-P" as above...  does -P also turn on extra debugging in Nightly?

I'm now sending them to a file**; the worst offenders after a few hours (while I was sleeping) are:

7370 times: WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/dom/base/nsGlobalWindow.cpp, line 9531
7370 times: WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x8000FFFF: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/dom/src/storage/DOMStorageManager.cpp, line 447
1155 times: WARNING: NS_ENSURE_TRUE(!(aRv.Failed())) failed: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/content/base/src/nsXMLHttpRequest.cpp, line 3670
578 times: WARNING: NS_ENSURE_TRUE(isFileURI) failed: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/content/base/src/ThirdPartyUtil.cpp, line 284
568 times: WARNING: NS_ENSURE_TRUE(mMutable) failed: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/netwerk/base/src/nsSimpleURI.cpp, line 265
1500+: {++,--}DOMWINDOW *

** Reducing output would be best; but I can live with the messages this way as it doesn't drag the system down as badly.
Thanks.
> Only if Nightly is a debug build by default...

It's not.  But you're definitely using a debug build, not a nightly.
(Reporter)

Comment 29

6 years ago
Then I'm confused about what http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-24.0a1.en-US.linux-x86_64.tar.bz2 delivers...

About Nightly gives 24.0a1 (2013-06-06)
That's a nightly, but that's not the build you're running given that output...
(Reporter)

Comment 31

6 years ago
Are you saying that Nightly (24.0a1 (2013-06-06)) is a debug build?  If the lower right link in the Desktop group at http://nightly.mozilla.org/ is a 64-bit *debug* build, then that's not flagged.  I understand you believe I'm running a debug build; but I _never_ went looking for one, or knowingly downloaded one...  Any chance this is a result of enabling the Developer Toolbar?

Back to the original bug...  any clue as to what else I can check for next?  The bug is consistently reproducible (comment 16 steps 1-5) on my default profile on this userid; but not on other userids, yet.
> I understand you believe I'm running a debug build;

I don't just believe it.  All the output you pasted above is #ifdef DEBUG, so you are definitely running a debug build.  That's all I can say for sure; I can't speak to where you got it or what's up on nightly.mozilla.org (though I just checked the link in comment 29 and it gives me an opt build).

> Any chance this is a result of enabling the Developer Toolbar?

No, because DEBUG is a compile-time macro.

As far as the bug, one good place to start is seeing if you can create a new profile (which presumably does not show the bug) and then copy in files one by one from the old profile until you can reproduce...
(In reply to Pierre Fortin from comment #31)
Make sure to quit the old Firefox (from launcher or anywhere else) before you start the latest version.
(Reporter)

Comment 34

6 years ago
No choice...  FF refuses to start until ALL of currently running FF is stopped.  After all windows are closed, there's several seconds where new FF won't start because some code still hasn't shutdown fully.

[bugzilla demanding that I "correct version, component"...  :? ]
Component: Layout → General
Product: Core → Firefox
(Reporter)

Comment 35

6 years ago
OK....  after lots of ~/.mozilla/* moving and testing, it appears the bug is triggered by something in my prefs.js.  However, it requires my sessionstore.js to partner with it to trigger the bug.  My sessionstore.js with a clean prefs.js doesn't produce the bug, and prefs.js with a mostly virgin sessionstore.js doesn't either...

I've removed most of the contents of prefs.js:capability.policy.maonoscript.site and all the entries related to my various printers (nearly 90K total) and the much smaller prefs.js triggers the bug (uploading it shortly).  Not uploading sessionstore.js -- too much personal data.

To reproduce the bug with these two files:
- start FF
- new tab
- google.com
- enter search term
- RELOAD search results page
- no bug
- open second new tab
- google.com
- enter search term
- RELOAD search results page
- BLANK page!!


My sessionstore.js is large (8488007) with much personal data.

Is there a tool to delete entries without destroying the integrity of its structure?  This would allow me to try to isolate the sessionstore.js content that colludes with prefs.js...
(Reporter)

Comment 36

6 years ago
Created attachment 760447 [details]
minimal prefs.js which triggers bug (my sessionstore.js needed however)
Attachment #760447 - Attachment mime type: application/octet-stream → text/plain
That doesn't look like the minimal prefs.js, but in practice is anything other than this line:

  user_pref("browser.sessionstore.resume_session_once", true);

needed?
(Reporter)

Comment 38

6 years ago
Hi Boris, No, as indicated, I removed a lot of stuff and retested.  Just created a prefs.js with only that line in it and the bug does not appear; so whatever is triggering it must be in Attachment #760447 [details]. With only that line, sessionstore.js did not get loaded.
So all the print and noscript and datareporting preferences are needed?
(Reporter)

Comment 40

6 years ago
Not likely.  As indicated above, I've already removed around 90KB of data before posting the attachment...  [checking more...]

Interesting...  maybe all that debug output is useful...

When the bug (blank page) occurs, I get this:
WARNING: We should have hit the document element...: file /builds/slave/m-cen-l64-dbg-st-an-ntly-00000/build/layout/xul/base/src/nsBoxObject.cpp, line 175

As specified in comment 16, if I reload the blank page, the search results appear; but this warning does not...  looks like a correlation...
(Reporter)

Comment 41

6 years ago
BTW...  just noticed this in that warning line:
m-cen-l64-dbg-st-an-ntly-00000/build/layout/xul/base/src/nsBoxObject.cpp
          ^^^       ^^^^
Reads like debug & nightly to me...  Like I said, never knowingly download a debug version....
There are definitely debug nightly builds done, but they shouldn't be getting linked from nightly.mozilla.org...

The boxobject warning happens if we call nsBoxObject::GetOffsetRect on a fixed position element, as far as I can tell.
Removing qawanted based on comment 18.
Pierre, any updates with this ?
Keywords: qawanted
(Reporter)

Comment 44

6 years ago
Hi Paul!  Weird...  I was running 25.0a1 (2013-06-30) when you asked and the problem didn't appear to be reproducible; but after upgrading to 25.0a1 (2013-07-10), the problem is still there...  Whatever it is is within the files in ~/.mozilla; but I haven't had time to dig deeper.  Are there documents describing the structures of the various files within that folder?
The current reproducibility is still:
- start FF
- new tab
- google.com
- enter search term
- RELOAD search results page
- no bug
- open second new tab
- google.com
- enter search term
- RELOAD search results page
- BLANK page!!
Tried restarting, entering a second search term on first new tab -- no bug.  So, opening a second new tab appears to be required to trigger the bug...

Comment 45

6 years ago
I can confirm with v24 that the issue is reproducible as soon as a 2nd tab is opened...even if it is blank.

Comment 46

6 years ago
UPDATE: It just happened again with only one single tab.

Comment 47

6 years ago
I realize this thread is old already...but here is a workaround which I tested thouroughly and I am able to reproduce the bug and illuminate it. So it seems this issue is tied in with 2 things? Firefox (v24 and others) and Google (site Tracking).

The WORKAROUND...install this plugin to BLOCK Google tracking until Firefox devs fix this obvious bug.
http://matagus.github.io/remove-google-redirects-addon/
(In reply to themadproducer from comment #45)
> I can confirm with v24 that the issue is reproducible as soon as a 2nd tab
> is opened...even if it is blank.
Couldn't reproduce on FF 24 Ubuntu 13.04 x64.

Comment 49

5 years ago
Note:
This bug at times is random....or not 100% consistent. But the workaround CONSISTENTLY fixes the issue for me. IMPORTANT: a restart of FF is needed before the Addon will do it's thing properly. 

BTW, on another PC with almost an identical setup, the bug does not happen.
Depends on: 908446
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
No longer depends on: 908446
Resolution: --- → DUPLICATE
Duplicate of bug: 908446
You need to log in before you can comment on or make changes to this bug.