1781083 - Server responding with a 4xx or 5xx with "Content-Length: 0" on navigation freezes currently open page

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Manuel Bucher [:manuel]]

STR:

1. open wiki.mozilla.org
2. click on Mobile view at the bottom of the page
3. The page freezes and becomes non-interactive. Trying to right click makes nothing happen

Expected result:

3. An error page is shown with the http status code

HTTP response when switching to the mobile view on wiki.mozilla.org (https://m.wiki.mozilla.org/index.php?title=Main_Page&mobileaction=toggle_view_mobile): (edit: That page doesn't return an error code anymore as of 2024-01-25)

curl -I 'https://m.wiki.mozilla.org/index.php?title=Main_Page&mobileaction=toggle_view_mobile'
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
Connection: keep-alive

And when opening https://github.com/canonical/firefox-snap/blob/stable/snapcraft.yaml#L231-L238 (edit: That page doesn't return an error code anymore as of 2022-07-29)

> curl -I 'https://github.com/canonical/firefox-snap/blob/stable/snapcraft.yaml#L231-L238' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' -H 'Sec-Fetch-Dest: document' -H 'Sec-Fetch-Mode: navigate' -H 'Sec-Fetch-Site: none' -H 'Sec-Fetch-User: ?1'
HTTP/2 406 
server: GitHub.com
date: Mon, 25 Jul 2022 15:12:16 GMT
content-type: application/x-yaml
vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, Accept-Encoding, Accept, X-Requested-With
permissions-policy: interest-cohort=()
cache-control: no-cache
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: no-referrer-when-downgrade
expect-ct: max-age=2592000, report-uri="https://api.github.com/_private/browser/errors"
content-security-policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; child-src github.com/assets-cdn/worker/ gist.github.com/assets-cdn/worker/; connect-src 'self' uploads.github.com objects-origin.githubusercontent.com www.githubstatus.com collector.github.com raw.githubusercontent.com api.github.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com cdn.optimizely.com logx.optimizely.com/v1/events *.actions.githubusercontent.com wss://*.actions.githubusercontent.com online.visualstudio.com/api/v1/locations github-production-repository-image-32fea6.s3.amazonaws.com github-production-release-asset-2e65be.s3.amazonaws.com insights.github.com wss://alive.github.com; font-src github.githubassets.com; form-action 'self' github.com gist.github.com objects-origin.githubusercontent.com; frame-ancestors 'none'; frame-src render.githubusercontent.com viewscreen.githubusercontent.com notebooks.githubusercontent.com; img-src 'self' data: github.githubassets.com identicons.github.com github-cloud.s3.amazonaws.com secured-user-images.githubusercontent.com/ github-production-user-asset-6210df.s3.amazonaws.com *.githubusercontent.com; manifest-src 'self'; media-src github.com user-images.githubusercontent.com/; script-src github.githubassets.com; style-src 'unsafe-inline' github.githubassets.com; worker-src github.com/assets-cdn/worker/ gist.github.com/assets-cdn/worker/
set-cookie: _gh_sess=FRLly6Zw9tpJL0n6HR8abgr48YmovRCjwpzDHrDkTKp%2BDHx0iZ2h69IkSDSxHOToDtjXz683SoGUNNZMPbqOsVrWRqfZnXEpEPUB0xXfLvobRmRhJuEx7TGCUl05ZChooOCKj0SBnT7Z4RQ87PfW13%2FcnBbsluqJdXBmx6LEW0blAR61rRIHWHzJk4YwG%2BTd4dR3kuzGotwxPOj850YDScnTtKQn7C3kViU8LYkqqGWpRe34bA7D7CiCcbI7nsyl4C8dZJmQWzk9RO5f6IUN0w%3D%3D--LZcF%2BUT3fEKb5FLL--6%2FDuuBRX%2BnWtT8JfD%2F4y%2BA%3D%3D; Path=/; HttpOnly; Secure; SameSite=Lax
set-cookie: _octo=GH1.1.931529799.1658761935; Path=/; Domain=github.com; Expires=Tue, 25 Jul 2023 15:12:15 GMT; Secure; SameSite=Lax
set-cookie: logged_in=no; Path=/; Domain=github.com; Expires=Tue, 25 Jul 2023 15:12:15 GMT; HttpOnly; Secure; SameSite=Lax
content-length: 0
x-github-request-id: EC8C:080C:213D8B:23C1D1:62DEB2CF

Comment 1

[Kris Maglione [:kmag]]

Matt or Nika, does this seem familiar to you? It reminds me of some other bugs Matt fixed when navigating to no content pages. It seems a bit different, though, in that it continues displaying the content of the previous content viewer rather than a blank page, but without being able to interact with it. I think the difference may just be that we now support displaying the previous content viewer in Fission while the navigation is in progress, where we didn't when the other bugs were fixed, so it may be the same issue.

Comment 2

[Nika Layzell [:nika] (ni? for response)]

Given that the previous page is non-interactive I wonder if this might actually be that because we receive no content, we never paint the new document which we just navigated to, meaning that we continue to paint the previous document indefinitely due to the grey flash avoidance work. ni? :emilio to see if that might be a thing and for any ideas for a workaround.

In terms of why we don't show an error page, I'm guessing we perhaps try to just render the response content for 406 responses?

Comment 3

[Emilio Cobos Álvarez (:emilio)]

I'm confused, that's not what I see locally on Windows?

When I go to wiki.mozilla.org, then click the Mobile View, I get a blank page (not an error page).

That's the same thing I get if I visit https://m.wiki.mozilla.org/index.php?title=Main_Page&mobileaction=toggle_view_mobile in a new tab.

The 503 error is still getting returned. What am I missing? Or is this somehow Linux-specific?

Comment 4

[Kris Maglione [:kmag]]

I'm seeing the same behavior as the reporter. I don't get an error page, just an unresponsive content viewer and empty urlbar when I click the link, or load that URL while any other page is loaded.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Huh, I see that on macOS... I wonder what's different from my Windows setup.

Comment 6

[Manuel Bucher [:manuel]]

The 503 error is still getting returned. What am I missing? Or is this somehow Linux-specific?

Tried with a new profile and the behavior changed from "freezing" to "previous page keeps usable". And when disabling uBlock origin in my main browser the previous page also keeps usable as if the link wasn't clicked at all. So might be caused by uBlock origin (installing uBlock in the new profile also started causing the freeze behavior).

I would still expect an error page (or a blank page?) instead of keeping the previous page on error. Is there a design decision to keep the last page? Is this a uBlock bug or still a Firefox bug?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

I still don't know what's going on tbh. On older builds, I can reproduce comment 6 (previous page keeps being usable). I can repro this even on mozregression but somewhat randomly (I couldn't get to a reasonable regression range).

If I go further back, we did use to show an error message, and stopped doing so somewhere in this range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c238b47d7d57e651a92b4f134641fa694e4ea900&tochange=930ad6def3c7961c82b2af20b66be3351603684f

There are various suspect things there (bug 1574372, bug 1603032...). Kris does something else in that range look particularly suspicious to you?

In any case I don't think it was intentional to stop showing the error page, given that regression range.

Comment 8

[Kris Maglione [:kmag]]

I'm still looking into it. I think f12433954ae57831bf6573865125562d9824d80 looks most likely. Apparently, because the server doesn't send a Content-Type header, we look at the file extension and interpret it as an "application/x-php" channel, and then try to find a converter or external handler before canceling. So I think we do wind up going through the download handling path that was causing one of the instances of this issue in the past, where we saw a broken blank content viewer rather than the contents of the previous content viewer (because that wasn't implemented yet).

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:sefeng, since the bug has high severity and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 10

[Sean Feng [:sefeng]]

Kris is looking into it, leaving it as is.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Based on comment #7, this bug contains a bisection range found by mozregression. However, the Regressed by field is still not filled.

:kmag, if possible, could you fill the Regressed by field and investigate this regression?

For more information, please visit auto_nag documentation.

Comment 12

[Kris Maglione [:kmag]]

We still haven't found the regressing bug

Comment 13

[Manuel Bucher [:manuel]]

Some observations (with uBlock installed):

• uBlock throws execptions when clicking: JavaScript error: moz-extension://30688acb-36a9-48e8-9eec-f833caf449e3/js/contentscript.js, line 1260: TypeError: ev.target.closest is not a function
• warnings when loading the page, clicking and moving the mouse out of the window:

[Parent 770585, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED): file /home/user/dev/gecko2/netwerk/ipc/DocumentLoadListener.cpp:262
[Parent 770585, Main Thread] WARNING: NS_ENSURE_TRUE(LoadIsPending()) failed: file /home/user/dev/gecko2/netwerk/protocol/http/nsHttpChannel.cpp:5711
[Parent 770585, Main Thread] WARNING: NS_ENSURE_TRUE(mSuspendCount > 0) failed: file /home/user/dev/gecko2/netwerk/protocol/http/nsHttpChannel.cpp:5736
[Child 770820, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805D0001 (NS_ERROR_WONT_HANDLE_CONTENT): file /home/user/dev/gecko2/uriloader/base/nsURILoader.cpp:164
JavaScript error: moz-extension://30688acb-36a9-48e8-9eec-f833caf449e3/js/contentscript.js, line 1260: TypeError: ev.target.closest is not a function
[Parent 770585, Main Thread] WARNING: 'nsContentUtils::GetCommonBrowserParentAncestor( remote, oldRemote) != remote', file /home/user/dev/gecko2/dom/events/EventStateManager.cpp:1488
[Child 770820, Main Thread] WARNING: DispatchEvent called on non-current inner window, dropping. Please check the window in the caller instead.: file /home/user/dev/gecko2/dom/base/nsGlobalWindowInner.cpp:4396

• https://searchfox.org/mozilla-central/rev/7426a35738cd542b9488c7b67f4f6d21edfeda0a/netwerk/ipc/DocumentLoadListener.cpp#262
• https://searchfox.org/mozilla-central/rev/7426a35738cd542b9488c7b67f4f6d21edfeda0a/netwerk/protocol/http/nsHttpChannel.cpp#5711
• https://searchfox.org/mozilla-central/rev/7426a35738cd542b9488c7b67f4f6d21edfeda0a/netwerk/protocol/http/nsHttpChannel.cpp#5736
• https://searchfox.org/mozilla-central/rev/7426a35738cd542b9488c7b67f4f6d21edfeda0a/uriloader/base/nsURILoader.cpp#164
• https://searchfox.org/mozilla-central/rev/7426a35738cd542b9488c7b67f4f6d21edfeda0a/dom/events/EventStateManager.cpp#1487-1488
• https://searchfox.org/mozilla-central/rev/7426a35738cd542b9488c7b67f4f6d21edfeda0a/dom/base/nsGlobalWindowInner.cpp#4394-4396

Comment 14

[Manuel Bucher [:manuel]]

After seeing the differences in behavior to Bug 1325876 I got a bit curious why we see the current page sometimes and sometimes a blank page. Using the following test server I can confirm that the behavior is based on our Content-Type guess based on file extension.

while [ 1 ]; do printf 'HTTP/1.1 503 Service Unavailable\r\nConnection: close\r\n\r\n' | nc -lN 8000; done

• current page stays visible:
  • http://localhost:8000/test.yaml
  • http://localhost:8000/test.php
• Blank page (instead of error page, Bug 1325876):
  • http://localhost:8000/
  • http://localhost:8000/test.html
• side note: image viewer with http://localhost:8000/test.png

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 16

[Sam Todderson]

Attachment: same problem

Thanks from galatabor1976.