Closed Bug 878456 Opened 12 years ago Closed 12 years ago

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

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
24 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 908446

People

(Reporter: u123541, Unassigned)

Details

Attachments

(12 files)

google.com source
104.04 KB, text/plain
Details
google.com OuterHTML
114.68 KB, text/plain
Details
google results Source
104.04 KB, text/plain
Details
google results OuterHTML
287.81 KB, text/plain
Details
wikipedia.org Source
242.56 KB, text/plain
Details
wikipedia.org OuterHTML
356.97 KB, text/plain
Details
googe results Back blank Source
101.12 KB, text/plain
Details
googe results Back blank OuterHTML
108.17 KB, text/plain
Details
google.com Back blank Source
101.12 KB, text/plain
Details
google.com Back blank OuterHTML
108.17 KB, text/plain
Details
Console output
7.77 KB, text/plain
Details
minimal prefs.js which triggers bug (my sessionstore.js needed however)
36.16 KB, text/plain
Details
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]
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...
Attached file google.com source —
Attached file google.com OuterHTML —
Attached file google results Source —
Attached file wikipedia.org Source —
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...
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...
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
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... :)
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...
Attached file 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 ?
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" ?
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
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 !!!
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?
[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.
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...
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.
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
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...
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?
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?
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...
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
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...
I can confirm with v24 that the issue is reproducible as soon as a 2nd tab is opened...even if it is blank.
UPDATE: It just happened again with only one single tab.
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.
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
Closed: 12 years ago
No longer depends on: 908446
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: