1611870 - Restoring pinned tabs sometimes leaves the tab with the right favicon but an empty url

Status: NEW

(Firefox :: Session Restore, defect, P3)

Description

[Emilio Cobos Álvarez (:emilio)]

Attachment: screenshot

I've noticed this twice already over the last couple of days... The url bar is empty when I look at some of my pinned tabs, even though the favicon is right, see attached screenshot.

Comment 1

[Maria Berlinger [:mberlinger], Services QA]

Hi Emilio,

Could you please provide some steps to reproduce?
I've tried to reproduce this issue but without success.

Thanks!

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I don't have any unfortunately, just being on a somewhat poor network connection and restarting the browser to update :(

Comment 3

[Maria Berlinger [:mberlinger], Services QA]

Could you still reproduce this issue with a clean profile as well?

Comment 4

[Bob Clary [:bc] (inactive)]

fyi: I see this occasionally but don't have reliable str. I usually have a couple of windows each with dozens of tabs with one window containing pinned tabs for sso properties. I see this occasionally when I restart after a Nightly update. A work around I've found that works for me is to go back in history one page and then back.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Well, I could try to use a clean profile for a couple days I guess, but as I said it doesn't happen reliably.

Comment 6

[Chris Peterson [:cpeterson]]

Perhaps bug 1614774 (tabs become empty, not during session restore) is related to this bug.

Comment 7

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

The priority flag is not set for this bug.
:mikedeboer, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This could also be a navigation issue, at least on the observations here: So far it affected Slack, Matrix and mana pinned tabs which might redirect to auth0 to check if the credentials are still valid.

Jens, can you find an owner for further investigation, please?

Comment 9

[Mike de Boer [:mikedeboer]]

These type of bugs that are hard to nigh impossible to reproduce usually end up in a state where we're not able to find a definite fix. This is partly due to the fact that sessionstore wires together and is very dependent on various parts of machinery in the browser, making analysis hard and time consuming.

That said, I think that the combination of redirects to auth0 in combination with a glitchy network as Sebastian mentions in comment 8 sounds like a plausible cause.

Comment 10

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

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

Comment 11

[Jens Stutte [:jstutte]]

(In reply to Mike de Boer [:mikedeboer] from comment #9)

These type of bugs that are hard to nigh impossible to reproduce usually end up in a state where we're not able to find a definite fix. This is partly due to the fact that sessionstore wires together and is very dependent on various parts of machinery in the browser, making analysis hard and time consuming.

That said, I think that the combination of redirects to auth0 in combination with a glitchy network as Sebastian mentions in comment 8 sounds like a plausible cause.

I read this as a request to untrack this for 74? Pascal?

Comment 12

[Pascal Chevrel:pascalc]

Yes, without clear STR, I don't think we have enough data to hope for a fix in 74 beta given where we are in the beta cycle now.

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

I have a copy of a profile which reproduces the issue with Nightly when launched. Is there anything I should check in the sessionstore.jsonlz4 (or its unpacked version)?