Closed Bug 1435077 Opened 6 years ago Closed 6 years ago

Missed tabs after restart browser

Categories

(Firefox :: Session Restore, defect, P1)

57 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: drive4ik, Assigned: daleharvey)

References

(Blocks 2 open bugs)

Details

(Keywords: dataloss)

Attachments

(3 files)

Attached image ff-missed-tabs.gif
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180128191252

Steps to reproduce:

1. Run FF
2. go to settings and check ~ "show last opened tabs and windows on start"
3. quick open >= 4 tabs by middle mouse button, tabs are opened without focus
4. don't activate any of this tabs
5. restart firefox and see: opened tabs are missed

this issue not replicate on FF 56, but replicate on 57 and above.

P.S. my english is not very well, see attached GIF animation of screen

Best regards


Actual results:

tabs are missed after start


Expected results:

tabs not to be missed :)
I too have confirmed this as a bug.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
20180201100326

(In reply to Vitaliy from comment #0)
> this issue not replicate on FF 56

I can reproduce it with the first Nightly 56 build (2017-06-13). What probably happened is that the pages actually managed to load during testing. It's easier to reproduce with larger pages, e.g.
1. https://commons.wikimedia.org/wiki/Commons:Picture_of_the_day
2. Zoom out so that more thumbnails are visible.
3. Quickly middle-click 6+ thumbnails.
4. Quickly close Firefox while at least some of the tabs haven't fully loaded.
Severity: normal → critical
Has Regression Range: --- → irrelevant
Has STR: --- → yes
Component: Untriaged → Session Restore
Keywords: dataloss
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug was classified critical on 1st February. It is now 2nd March (after 1 month) and still no P priority.
What is this bug's P priority?
Flags: needinfo?(mdeboer)
I don't know, depends on the following:

Gingerbread Man, can you tell me if this can still be reproduced on a recent Firefox Nightly? I've worked on a couple of reliability improvements, which might've helped here.

However, I don't think that this is critical when I look at the STR in comment 2, so I'm putting this at a P4 right now.

PS: I'm behind on triage, so thanks for the ping, brunoais.
Flags: needinfo?(mdeboer) → needinfo?(gingerbread_man)
Priority: -- → P4
(In reply to Mike de Boer [:mikedeboer] from comment #4)
> However, I don't think that this is critical when I look at the STR in
> comment 2, so I'm putting this at a P4 right now.

Hi!

Have you seen attached gif animation ff-missed-tabs.gif?
Do you really think that this is not a critical bug?

I agree that I did not completely thoroughly testing on FF56, but this is really a critical bug.
Well, sure, but I just can't reproduce this on my Nightly build locally... so it doesn't look like a critical problem to me.
Strange, but I still have it replicated
I attached new gif ff-bug-missed-tabs-2-March-2018.gif
My system: Win 10 Pro (x64) with latest updates, 16GB RAM, Intel i7, integrated graphics card
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
20180302104326

(In reply to Mike de Boer [:mikedeboer] from comment #4)
> Gingerbread Man, can you tell me if this can still be reproduced on a recent
> Firefox Nightly?

Yes, I can still reproduce this in a fresh profile with the STR from comment 2.
Only the original tab at step 1 was restored; all the tabs opened in the background were lost.

> However, I don't think that this is critical when I look at the STR in
> comment 2

If you mean this isn't urgent or high priority, I have no comment on that. But lost tabs means loss of data, and data loss is supposed to be marked severity: critical.
"critical 	Crashes, loss of data, severe memory leak"
https://wiki.mozilla.org/BMO/UserGuide/BugFields#priority
Flags: needinfo?(gingerbread_man)
I suppose gingerbread man forgot to needinfo you
Flags: needinfo?(mdeboer)
The issue seems pretty critical in my opinion... Has this stalled?
This bug is *VERY* annoying. I'm a heavy simple-tab-groups user and I have to load a backup every time I start FF. Unfortunately the backup doesn't retain any login in info just tab URLs.
I have loaded FF 60 onto my old work laptop (they called be back yay). I do not see this issue on it. Are there any logs or other data I can supply from systems where it appears vs doesn't appear? Right now I've moved back to FF ESR to avoid this issue and it is glacially slow.
This problem appears in FF ESR 52.7.3 but to a lesser extent. Upon reflecting upon my FF usage this problem has ALWAYS appeared when using any tabgroup addon. I just lost about 100 tabs because I didn't do a manual backup of my tabs (which I shouldn't have to do). About 25 of them were tabs with links to medical sites.

I restate my willingness to assist in finding and debugging the problem.
I can easily reproduce this with a new portable install of Firefox 61. Though it seems like if you wait 5-10 seconds between opening the tabs and closing Firefox the tabs get eventually saved. Only if you close Firefox within that timeframe the tabs are lost.

Since they are silently lost, even without warning or error, I would definitely consider this a critical bug (and I will wait for this to get fixed before updating from my current v56).

Is this at least being worked on?
(In reply to manny123 from comment #15)
> I can easily reproduce this with a new portable install of Firefox 61.
> Though it seems like if you wait 5-10 seconds between opening the tabs and
> closing Firefox the tabs get eventually saved. Only if you close Firefox
> within that timeframe the tabs are lost.
> 
> Since they are silently lost, even without warning or error, I would
> definitely consider this a critical bug (and I will wait for this to get
> fixed before updating from my current v56).
> 
> Is this at least being worked on?

Status: Unassigned (NeedInfo from mikedeboer)

This critical bug has been open for months with no traction. How can we get this more attention?
Flags: needinfo?(mikedeboer.mozbugs)
This bug appeared more frequently after FF 57 but I think it has been around for a while. I've had a similar problem with FF ESR. Closed FF. Later opened to find ALL tabs gone. FF61 with Simple Tab groups 3 seems to be ok (Simple Tab groups seems to exacerbate the problem).

And yeah I'd say it is critical after losing about 100 tabs.
The correct account was needinfo'd, I just didn't have the time to dive into this until now. Sorry about the delay, but we're a small team working on a huge project - so this sometimes happens.
On the other hand, the previous releases did contain quite a number of sessionstore reliability fixes and improvements, so I'm interested in hearing whether you can still reproduce this issue on Firefox 61 or even 62.

(In reply to manny123 from comment #15)
> I can easily reproduce this with a new portable install of Firefox 61.
> Though it seems like if you wait 5-10 seconds between opening the tabs and
> closing Firefox the tabs get eventually saved. Only if you close Firefox
> within that timeframe the tabs are lost.

This is interesting and somehow I can reproduce this now on Windows. Finally! I'll be working on this to figure out what the cause may be.
Flags: needinfo?(mikedeboer.mozbugs)
Flags: needinfo?(mdeboer)
Assignee: nobody → mdeboer
Status: NEW → ASSIGNED
Priority: P4 → P1
Dale, can you start the investigation here? My queue doesn't permit me to check this out any sooner. :(
Assignee: mdeboer → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(dharvey)
ok yup managed to reproduce, will look into
Assignee: nobody → dharvey
Flags: needinfo?(dharvey)
ok so now having a hard time reproducing this, both recent debug and obj builds on windows, I go to https://commons.wikimedia.org/wiki/Commons:Picture_of_the_day and Ctrl + click 7 pictures and close the window as soon as possible, I get the same tabs each time I restart

Anyone able to reproduce this on latest nightly and share how?
Vitaliy are you able to reproduce this on a current nightly, I have the same machine setup as you and have been trying again but unable to reproduce
Flags: needinfo?(drive4ik)
I haven't seen this issue since FF 60.
Did you try with many tabs (1000+)?
Flags: needinfo?(dharvey)
Flags: needinfo?(brucea.williamson)
Also I am not sure if bug 1435077 (this one) should block bug 1235231?
I think that they are completely independent. Bug 1235231 happens without missing tabs - just order of windows is changed.
Hi Dale Harvey! I do not know what happened, but now this problem does not repeat itself.
Please see no-missed-tabs-27.08.2018.gif
Flags: needinfo?(drive4ik)
My system 3 ~ 4 weeks ago had a big update, maybe it affected somehow.
current version: Windows 10 Pro 1803
Os build: 17134.228
(In reply to Robert Ab from comment #24)
> Did you try with many tabs (1000+)?

I do not have that many tabs. I have 264 in 5 groups (I'm using Vitally's simple tab groups addon). This problem was originally reproducible with only a few tabs.

Also, I was in error when I stated FF60 fixed the issue. The problems seems to have gone away after FF61. 

Prior to FF61 I had a workaround. Switch to a tab group whose content was don't care. Close FF. Upon restarting other groups would load. The don't care group would be lost. Other groups would be at some previous time. Later I saved the groups to reload.

As I stated above even with FF ESR I saw sometime similar. I would have my main group open (100+ tabs). Close FF. start FF and my tabs would be gone.


I know it's a lot but my memory on issues is serial.  :) And I provide it hoping that it will help.
Flags: needinfo?(brucea.williamson)
ok took a long time to test this with 100+ tabs but still cant reproduce and with reporter + others verifying they can no longer reproduce closing as WFM, thanks all
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(dharvey)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: