Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Cuireadh an snáithe seo sa chartlann. Cuir ceist nua má tá cabhair uait.

Google search page functions broken.

  • 26 freagra
  • 1 leis an bhfadhb seo
  • 313 views
  • Freagra is déanaí ó b.j.p.5252

more options

When I go to google.com and do a search the results page has the "tools" button but it does not work. The "people also ask" categories are also broken (they will not expand), and, if I click the "images" filter button to view images associated with my search it either shows no images (or only a few images) and a bunch of blank boxes. I have found that if I hold the shift key and click the reload button everything is back and working properly until the next time I do a google.com search, then it is back to the same odd behavior. So, my assumption here is that either a cookie or some site data is corrupting the results page for my search. Running Firefox 92.0 (64-bit) on a Windows 7 Dell machine and everything was working fine until about two months ago. Also, Chrome does not show the same behavior. BTW. I have also done everything I have found that was recommended to fix Firefox issues with Google search. Run Firefox in private mode, run without plugins, changed themes, created new profile, I even completely uninstalled Firefox and did a clean install all with the same results. Any help is appreciated. It is almost got me ready to move back to Chrome.

When I go to google.com and do a search the results page has the "tools" button but it does not work. The "people also ask" categories are also broken (they will not expand), and, if I click the "images" filter button to view images associated with my search it either shows no images (or only a few images) and a bunch of blank boxes. I have found that if I hold the shift key and click the reload button everything is back and working properly until the next time I do a google.com search, then it is back to the same odd behavior. So, my assumption here is that either a cookie or some site data is corrupting the results page for my search. Running Firefox 92.0 (64-bit) on a Windows 7 Dell machine and everything was working fine until about two months ago. Also, Chrome does not show the same behavior. BTW. I have also done everything I have found that was recommended to fix Firefox issues with Google search. Run Firefox in private mode, run without plugins, changed themes, created new profile, I even completely uninstalled Firefox and did a clean install all with the same results. Any help is appreciated. It is almost got me ready to move back to Chrome.

Réiteach roghnaithe

Was that with the Norton enabled or disabled? It's still trying and failing to make a conduit to SymBfw.js (Ah, Sym for Symantec), plus "XHRGET https://ratings-wrs.norton.com/brief?url=https://www.google.com/search". I no longer think that's your problem, but if it was supposed to be disabled/uninstalled when you recorded this we should look into why those two things are still happening. Separate question though!

Thank you very much for this detailed log. The one thing that jumps out at me is that the initial request uses HTTP/3 and the shift-reload falls back to HTTP/2. I'm not confident this is an important difference: my own browser does this and I'm not seeing the problem. This could explain why Shift-reload made a difference even though the cache clearly didn't.

The script it's failing on is the first and biggest chunk of application script so it's easy to see why the page is broken after that point. not much clue why it broke in the first place :-( Could Norton beinterfering with HTTP/3 somehow, external to the browser? A proxy, maybe? I know those anti-virus products like to inspect network traffic so it's conceivable, but Norton is so popular that surely we'd have plenty of reports by now if that were the case. Clearly _some_ HTTP/3 is getting through because the page loaded enough to start loading the scripts.

All that to say: let's try disabling HTTP/3 and see if that fixes your problem, but it might not. You can live without HTTP/3 -- all the sites that support it fall back to support older browsers

1. open the advanced preference page about:config. Agree to be careful if asked 2. type http3 in the filter box 3. double-click network.http.http3.enabled to set it to false

How long did you say you've had this problem? We shipped HTTP/3 in Release versions around April or May 2021.

Read this answer in context 👍 0

All Replies (20)

more options

Make sure you are not blocking content.

Diagnose Firefox issues using Troubleshoot(Safe) Mode {web link}

A small dialog should appear. Click Start In Troubleshoot(Safe) Mode (not Refresh). Is the problem still there?


https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop


Many site issues can be caused by corrupt cookies or cache.

Warning ! ! This will log you out of sites you're logged in to. You may also lose any settings for that website.

more options

b.j.p.5252 said

I have found that if I hold the shift key and click the reload button everything is back and working properly until the next time I do a google.com search, then it is back to the same odd behavior. So, my assumption here is that either a cookie or some site data is corrupting the results page for my search.

Shfit-clicking the Reload button, or Ctrl+Shift+R, or Ctrl+F5 all do a reload bypassing cached files. So this implies the problem is a cached file, or possibly modifications made by add-ons that leave the page broken when you restore it or go back to it.

How often does this problem occur, for example, after restoring a tab from a previous session versus all day long. Can you associate it with particular actions?

more options

FredMcD: none of those suggestion fix the issue and I had tried most of them before my posting. jscher2000: I agree with you that is something cached. The problem occurs when I have closed the browser then come back at a later time. If I do a shift/reload I can then surf the web all day long if I want and come back to google.com and the search page functions normally. But, as I said, if I close the browser and come back later, do a google search, the problem is back. I have also discovered that if I open the Browser Console, delete the entries and refresh the page until I get a Cookie “DV” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite message the page will then function normally. I do have Firefox set to clear the History when closed and to delete cookies and site data when Firefox is closed. Although changing those settings does not fix the issue. I only have two extension: Norton Safe Web and Printable - The Print Doctor. Disabling them has no effect. I also have just the System Theme installed, but I have tried several other themes which did not fix the issue. I have also disabled my Norton protection (both the firewall and Auto-Protect) and that did not fix the issue either.

more options

b.j.p.5252 said

I do have Firefox set to clear the History when closed and to delete cookies and site data when Firefox is closed. Although changing those settings does not fix the issue.

Hmm, shouldn't be the cache if you are clearing cache at shutdown. The "Clear history when Firefox closes" feature has a Settings button to choose categories of data to clear. Are you clearing the cache?

Is Google loading automatically in your new session (it is your home page), or are you going to the site either manually or using a bookmark?

Users have observed some issues with Yahoo! not loading fully when set as their home page, but I don't remember hearing of that issue with Google before.

more options

Yes, I am clearing the cache in the Clear history when Firefox closes. Yes, Google is my homepage, but even if I set my home page to a blank page then go to google.com the behavior is the same. Still can't fathom why the shift/reload does the trick as I thought the same as you about the cache being emptied on close. It has to be something google is putting in the cache on page load. The browser console cookie rejection is a head scratcher as well.

more options

It could be the cache has a problem.

Location of the cache/cache2 folder; Windows: *C:\Users\<user>\AppData\Local\Mozilla\Firefox\Profiles\<profile>\ Mac: ~/Library/Caches/Firefox/Profiles/ Linux: ~/.cache/mozilla/firefox/

Close Firefox. Open your file browser to the above and remove the folder.

more options

b.j.p.5252 said

The browser console cookie rejection is a head scratcher as well.

You can ignore that part, it's just a warning for developers for the future. But maybe it's relevant that the site needed to reset that cookie after the page reload??

more options

FredMcD: I tried deleting the cach2 folder (I do not have a cache folder) and it made no difference. I also tried deleting the shader-cache and startupCache folders as well but neither fixed the issue.

jscher2000 and FredMcD: I appreciate all the effort you are giving to my problem. Any other suggestions??? Is there something special or different about what the shift/reload routine does that we are overlooking???

Again, Thanks.

more options

We could try to distinguish between cache and some other things it might be saving (cookies? IndexedDB?):

Open DevTools Switch to the Network Tab Make sure "Disable Cache" in the DevTools toolbar is checked Do your Google thing with DevTools open.

Can you still reproduce, or does this emulate the "Shift-reload" that fixes it?

This is a real stumper -- I can't think of any reason caching should make any difference.

Athraithe ag dveditz ar

more options

dveditz: Disable Cache in the DevTools does NOT emulate the shift/reload and does not fix the issue (with that option still checked in DevTools the shift/reload still works to fix the problem). This fact along with the Browser Console message "Cookie “DV” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite" that I get as I described above really makes me think it is a cookie issue and not a cache issue. However, I have tried stopping all cookies from google and that did not work either. I have also tried letting the browser always keep google cookies and that also had no effect so I just don't know. Just FYI, there are times that the google page will not fully load without a refresh, but that does not happen that often. Maybe back to Chrome is my only option.

Athraithe ag b.j.p.5252 ar

more options

The Cookie warning is not relevant -- no action is taken, it's just a warning to developers about a future change. This is a change the Chrome team has championed and they also plan to do. We are likely to let them go first so sites fix their breakage.

Shift-reload does not clear or change cookies.

This problem appears to be unique to you. If it's not an addons problem, nor a settings problem, maybe some of your profile databases are corrupt. We tried thinking it's a cache problem, but if you think it's a cookie problem you could try deleting that database (when Firefox is closed, of course!). You say you clear cookies on shutdown normally so that should cause no dataloss.

A final step would be to try a "Firefox Refresh" which rebuilds all these databases from scratch, but also resets some settings and removes all your addons. Although you did initially say you created a new profile and still encountered the problem so I guess that's not worth the hassle.

Do you have any security software or proxies external to Firefox, maybe something like pi-hole, that might be blocking some traffic?

more options

dveditz: I have tried deleting (one at a time) every sqlite file in my profile (including cookies, permissions, etc.) and nothing worked. I have also tried a "Firefox Refresh" and got no satisfaction. I have no proxies external to Firefox and I have tried disabling my Norton firewall and Auto-protect, also with no fix.

Thanks to all...I guess we just give up and I go back to Chrome :(

more options

You could try the cheat that Yahoo users came up with, which was to use a home page address that always redirects, as a way to force the reload. Maybe this will work for you? in the Custom URLs box:

http://google.com/

(That redirects to https://www.google.com/, potentially with an additional parameter about the insecure to secure upgrade.)

more options

jscher2000: No luck. It is just so frustrating that the shift/reload works, and that I have no problems with google in any other browser...it HAS to be a Firefox issue, evidently, only on my machine.

more options

Actually, I just tried it with an old (version 11) of Internet Explorer and the tools button and all filters (like the images button) do not work in it either. I have not used IE for years but I dusted it off just to see what it would do.

more options

Interesting... I don't see the problem with Internet Explorer either, running on Windows 10. Could Google be seeing Windows 7 in the User Agent and sending different content? That would be a little strange (sending different content to different browsers like Firefox and Internet Explorer is relatively common for Google, though).

If you're running Windows 7 then you might also be running a 32-bit build. That also shouldn't affect these symptoms, but it might be a difference? The "About Firefox" dialog says if it's 64-bit or not. Can't remember if it explicitly says "32-bit" or if that's just the absence of "64-bit".

You could try spoofing Chrome and see if they send you different content? It's a long shot, but none of this is making any sense at this point so we might as well rule it out. 1. open "about:config" -- Agree to be careful if you haven't used this before 2. in the filter box at the top type: general.useragent.override 3. click the "String" radio button and click the plus sign on the right 4. type the following string and hit enter after: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome 93.0.4577.63 Safari/537.36

See if you get any different behavior if Google thinks you're Chrome on Win10. When you're done testing go back to the about:config page, type enough of "general.useragent.override" to make it show up, and click the trashcan icon on the right.

I'm sorry this is so frustrating. With all the things you've ruled out your symptoms are completely mystifying and make zero sense.

more options

dveditz: Just to test the thought that IE might be involved, I uninstalled (or I should say I turned IE off from the control panel) and it made no difference. About Firefox shows I am running 92.0 (64bit). The about:config spoof of Chrome did make google pages much different, in a worse way. The input box was way off center and the search results page had no filter buttons (like the images button) and no "Tools" button at all. The results page also had no images on it at all so I would say that did not fix the issue either. I totally agree with you that none of this makes any sense since Chrome and Opera both function normally. And, since I turned IE off and then back on, even it is functioning properly now. I have been frustrated over this for about two months now and I am just about ready to go back to Chrome. And with the Firefox 92.0 update that made the bookmarks drop down menus spacing so large (I have several bookmark folders that have quite a few bookmarks in them and now they scroll off screen which is a pain) I can just add that as another reason to switch back to Chrome. Thanks for all the help.

more options

A little FYI: I found this very interesting. I disabled caching completely in Firefox (about:config - browser.cache.disk.enable = false) and the google search behavior was the same (no Tools button working, no People Also Ask expanding, and no images showing just as before and the shift/reload routine fixed it, just as before). I also verified that Firefox was not caching by looking at the cache2 folder and it was empty with browser.cache.disk.enable set to false. So caching is not, evidently, the problem. I would still like to know just exactly what the shit/reload does. If it just reloads the page and just bypasses the cache why would it still resolve my issue if caching was turned off??

more options

A little more FYI: In experimenting with the browser console (as you may recall I mentioned it above) I have found I get these entries for the search page on initial loading;

- WebExtensions: reset-default-search: starting. api.js:183 - WebExtensions: reset-default-search: has already ran once and saw panel, exit. api.js:210 - Error: Please use $(ref:runtime.getURL). background.js:26 - primed listener not re-registered ExtensionCommon.jsm:2315 - Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”). 3 moz-extension:7:6810 - Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 3 SymBfw.js:115 sendMessageToTab moz-extension://0bd18f96-ba4b-47f9-b2f6-04c696bea458/SymBfw.js:115 - Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” browser.xhtml - MouseEvent.mozPressure is deprecated. Use PointerEvent.pressure instead. www.google.com:22:153 - AbortError: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved ConduitsParent.jsm:297 - Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 3 SymBfw.js:115 sendMessageToTab moz-extension://0bd18f96-ba4b-47f9-b2f6-04c696bea458/SymBfw.js:115 - downloadable font: font-display timeout, webfont not used (font-family: "Google Sans" style:normal weight:400 stretch:100 src index:0) source: https://fonts.gstatic.com/s/googlesans/v14/4UaGrENHsxJlGDuGo1OIlL3Owp4.woff2

This is when the problem is present. Then if I clear the console (the trash can in the browser console) and do a shift/reload, this is what the console then shows;

- Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified 2 - AbortError: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved ConduitsParent.jsm:297 - Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 2 SymBfw.js:115 sendMessageToTab moz-extension://0bd18f96-ba4b-47f9-b2f6-04c696bea458/SymBfw.js:115 - Cookie “DV” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite m=attn,cdos,cr,dpf,hsm,jsa,d,csi:542:412 - This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://firefox-source-docs.mozilla.org/performance/scroll-linked_effects.html for further details and to join the discussion on related tools and features! search

This is when the problem is fixed and the search page functions normally. Now I know it was said to ignore the Cookie "DV" will soon be rejected because it has the "SameSite" attribute set to "None" or.....but this is the only entry in the console that is consistent with fixing my issue. When I just reload (not shift/reload) the console usually shows these entries;

- AbortError: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved ConduitsParent.jsm:297

- Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 2 SymBfw.js:115

And my problem persists. When I keep reloading (again, not shift/reload) until I get these entries in the browser console;

- AbortError: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved ConduitsParent.jsm:297

- Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 2 SymBfw.js:115

- Cookie “DV” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite m=attn,cdos,cr,dpf,hsm,jsa,d,csi:542:412

My problem is then fixed. This is why I originally felt the cookie rejection was the problem to begin with and why I experimented with always rejecting and always keeping cookies from google (of which neither setting was a fix). It just keeps getting curiouser and curiouser as Alice would say...and I feel like I have, indeed, gone down the rabbit hole.

more options

I wouldn't have expected any changes in IE to affect Firefox, it was just an interesting clue that the problem is in the alternate content sent to Firefox and other browsers compared to Chrome. The userAgent spoofing was just a test. Google definitely uses Chrome-only features in many places that will break when served to Firefox, but I didn't expect the relatively straightforward search-results page to be so different.

Sadly the cache is not yet off the hook: we also have a memory cache. In about:config set browser.cache.memory.enable = false at the same time as you disable the disk cache.

I've looked at our code and Shift-reload really only does a reload forcing a bypass of the cache (including ServiceWorkers, but the Google search page doesn't have any). Nothing else

Most of the "Browser Console" output is from the browser itself and web extensions and not relevant to any particular page. I see you've turned on the "Show Content Messages" option. You could also use the "Web Console" (part of Web Developer Tools) to see only the web content messages.

In your initial chunk of logging (when you say you see the problem) everything I see there looks like "Browser Console" output except the last message about the downloadable font, which comes from the page content. On my own Browser Console I see the two "reset-default-search:" messages at startup, but I don't see any of the others that you're getting. Those are all related to some web extension you have. The "Conduit" errors are from Firefox code, but it appears an those are triggered by an extension not passing messages correctly. I don't know what extension has SymBfw,js in it, but I can't help but be suspicious that whatever extension that is is related to the problems you're having.

On the other hand, the "Conduits destroyed" and "Could not establish connection" errors appear whether or not the page is going to work so maybe it's fine.

I also see the Cookie "DV" same-site warning you see. This cookie is set from a script loaded by the Google web page rather than a cookie set during a network request. Kind of hard to say whether that script file was always loaded and that functionality wasn't called for some reason, or whether that script file is only loaded in the "working" case.

I'd really like to know what Web Extension is throwing those errors, and if disabling it helps at all. Do you have a bunch of extensions, or do you think you could figure out which it is? The key is figuring out what "moz-extension://0bd18f96-ba4b-47f9-b2f6-04c696bea458" is -- those codes are generated uniquely on install for privacy/tracking reasons. Here's the non-obvious way to figure it out: 1. open the page "about:memory" 2. click the leftmost/first "Measure" button 3. search for the string "moz-extension://0bd18f96-ba4b-47f9-b2f6-04c696bea458" => on the matching line you'll find the extension name and permanent ID. What are those? (I need both, because names aren't unique but IDs are)

(putting that mapping in about:addons or about:support would have been handy but they didn't. There might be an easier trick, but this the one I know)

Let me know if disabling that extension helps at all. This could well be just another red herring, but at least it will remove some clutter from the Console output.

It looks like your console output isn't showing "requests". Click the buttons at the top of each console to enable "requests" and "xhr". The next thing to do would be to re-test and see how the individual network requests differ

  1. 1
  2. 2