1745770 - Tab loading spinner can spin forever

Status: RESOLVED DUPLICATE of bug 1745626

(Core :: DOM: Networking, defect)

Description

[Nicolas Silva [:nical]]

Attachment: Screenshot from 2021-12-13 17-41-13.png

I can reproduce this on fastmail.com (logged in) with my two linux machines on nightly.

The tab "spinner" never stops bouncing back and forth. In the gecko profiler I see that there is a request that never completes (see attached image).

I don't know whether the request never completing is an issue at all, but I believe that we should at least stop animating the UI after a certain time for power usage's sake.

Comment 2

[Nicolas Silva [:nical]]

In chromium, the tab stops animating after a while, same with epiphany.

Comment 3

[Nicolas Silva [:nical]]

Marking as security/restricted since I put an url which potentially sensitive info in it.

Comment 4

[Nicolas Silva [:nical]]

Another way to reproduce at least the UI aspect of this is to open a pdf without vieweing it, for example right click > open in a new tab this one: https://raw.githubusercontent.com/BelaPlatform/bela-pepper/master/Design%20Files/Schematic/pepper-rev2b.pdf and don't switch to the new tab.

There seem to be something that only "completes" when the pdf is actually displayed, until then the spinner will spin. If the pdf is a pinned tab it means that it will always continue animating until shown (since pinned tabs are loaded at startup).

Comment 5

[:gerard-majax]

As mentionned on Matrix, I have been experiencing the issue on Fastmail for a few days, even opened a case at them.

Comment 6

[:gerard-majax]

11:43.14 INFO: Running autoland build built on 2021-12-09 13:51:10.027000, revision 5968a282
11:58.92 INFO: Launching /tmp/tmpzainxlok/firefox/firefox
11:58.92 INFO: Application command: /tmp/tmpzainxlok/firefox/firefox -profile /tmp/tmpes65twrd.mozrunner
11:58.93 INFO: application_buildid: 20211209132939
11:58.93 INFO: application_changeset: 5968a2827351e9c1e64305f1673d8e578b852a46
11:58.93 INFO: application_name: Firefox
11:58.93 INFO: application_repository: https://hg.mozilla.org/integration/autoland
11:58.93 INFO: application_version: 97.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): bad
12:20.91 INFO: Narrowed integration regression window from [8353ad6d, 7cf66bf1] (3 builds) to [8353ad6d, 5968a282] (2 builds) (~1 steps left)
12:20.91 INFO: No more integration revisions, bisection finished.
12:20.91 INFO: Last good revision: 8353ad6df753e15ed28efb67394125b0bfbbf3d6
12:20.91 INFO: First bad revision: 5968a2827351e9c1e64305f1673d8e578b852a46
12:20.91 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8353ad6df753e15ed28efb67394125b0bfbbf3d6&tochange=5968a2827351e9c1e64305f1673d8e578b852a46

Comment 7

[:gerard-majax]

It looks like your fix for bug 1311726 generated this regression, from the bisection I performed above on the fastmail repro steps

Comment 8

[:gerard-majax]

Looks like it's dupe of bug 1745626

Comment 9

[Andrew McCreight [:mccr8]]

I've hidden the image and comment that contained a URL with potentially sensitive information in them, so I'm unhiding this bug now.