Closed
Bug 1388297
Opened 7 years ago
Closed 5 years ago
Firefox does not allow reopening closed tabs that were about:newtab
Categories
(Firefox :: Session Restore, defect, P3)
Firefox
Session Restore
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: dietrich, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression)
57.0a1 (2017-08-07) (64-bit) Mac OS X (latest)
STR:
1. Open a new tab.
2. Get completely distracted by those tempting Pocket recommendations, but don't click on any of them.
3. Close the tab.
4. Hit cmd/ctrl+shift+T to undo the closing of that tab.
Expected: That newly-closed tab is reopened.
Actual: Tab strip spins wildly to a whole other spot and reopens some tab I closed a while back, totally freaking me out and wondering what the heck is going on.
Updated•7 years ago
|
Blocks: ss-reliability
Updated•7 years ago
|
Keywords: regression,
regressionwindow-wanted
Reporter | ||
Comment 2•7 years ago
|
||
(In reply to Alice0775 White from comment #1)
> may be duplication of Bug 1388628
Hm, looks quite different. This isn't about a restart.
This is strictly about how about:newtab tabs are restored when doing undo-closed-tab.
This might be the intended behavior. It's a pretty terrible experience though.
Not only is it disruptive but if you have a large session with many tabs(100+)
Sometimes undo-closed-tabs quickly restores wrong tab even if they were loaded/unloaded or closed in different order.
Most of the times with heavy sessions wrong tabs are restored.
Reporter | ||
Comment 4•7 years ago
|
||
(In reply to shellye from comment #3)
> Not only is it disruptive but if you have a large session with many
> tabs(100+)
> Sometimes undo-closed-tabs quickly restores wrong tab even if they were
> loaded/unloaded or closed in different order.
>
>
> Most of the times with heavy sessions wrong tabs are restored.
Yikes! That is a very different problem, however. Can you report a new bug for that?
(In reply to Dietrich Ayala (:dietrich) from comment #4)
> (In reply to shellye from comment #3)
> > Not only is it disruptive but if you have a large session with many
> > tabs(100+)
> > Sometimes undo-closed-tabs quickly restores wrong tab even if they were
> > loaded/unloaded or closed in different order.
> >
> >
> > Most of the times with heavy sessions wrong tabs are restored.
>
> Yikes! That is a very different problem, however. Can you report a new bug
> for that?
Don't have a proper STR except happens with large sessions(50+ tabs)
and started with bug 906076 landing
Comment 6•7 years ago
|
||
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Firefox: 57.0a1, Build ID 20170815100349
I have tested this issue on Windows 10 x64, with the latest Firefox release (55.0.1) and the latest Nightly (57.0a1) build. I have managed to reproduce it using the steps provided in the description. Considering this, using the Mozregression tool, I have managed to find a regression:
Last good revision: 94a51a3b64d4 (2011-01-29)
First bad revision: 1c6e36066e73 (2011-01-31)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=94a51a3b64d4&tochange=1c6e36066e73
From this pushlog, bug 581937 stands out. However, after I read the comments, it seems that this issue is an intended behavior which was implemented in Firefox 4.0b11, after the bug 581937 was fixed.
Paul, can you please give us your opinion related to this change?
Flags: needinfo?(paul)
Updated•7 years ago
|
status-firefox55:
--- → affected
status-firefox56:
--- → affected
status-firefox57:
--- → affected
status-firefox-esr52:
--- → affected
Keywords: regressionwindow-wanted
Reporter | ||
Comment 7•7 years ago
|
||
Thanks Marius!
Redirecting ni? to contemporary module owner.
Flags: needinfo?(paul) → needinfo?(mdeboer)
Updated•7 years ago
|
Comment 9•7 years ago
|
||
fix-optional means that we will not block the release on this bug nor consider it top priority for this release. I don't see anything critical about restoring empty tabs, so whenever a fix is available we will take it. That is assuming this is determined to be an actual deviation from the intended behavior, which as comment 6 points out is not very likely.
Comment 10•7 years ago
|
||
Maybe the switch to a new (activity stream) about:newtab page warrants a change in behaviour here, but certainly not for pre-AS releases. I also don't think this is severe enough that, with the module owner away, we need to scramble to "fix" this for 58. I'm also not sure how entangled (or not) this is with general "is this an empty tab" logic this is, which would make fixing this more complex, so I'm going to go out and mark this wontfix for 58 (which will be released before Mike is back).
Note: this is specifically regarding whether or not "undo close tab" can undo closing new tab pages, not about anything else like issues with restoring sessions or race conditions in undo close tab generally, which should all have their own bugs.
status-firefox58:
--- → wontfix
status-firefox59:
--- → affected
Priority: -- → P3
Summary: Firefox no longer reopens closed tabs that were about:newtab → Firefox does not allow reopening closed tabs that were about:newtab
Updated•7 years ago
|
status-firefox60:
--- → wontfix
status-firefox61:
--- → fix-optional
Comment 12•5 years ago
|
||
about:blank, about:home and about:newtab without prior history (one-offs) pages are excluded from the sessionstore closed tabs list, to keep the session to restore on browser restart clean.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(mdeboer)
Resolution: --- → WONTFIX
Reporter | ||
Comment 13•5 years ago
|
||
Er, you've closed the bug with a reason that doesn't acknowledge any of the concerns about the poor user experience, or provide a cost vs benefit rationale for "clean session next restart" relative to it.
This way of issue handling really makes contribution a bummer experience :(
You need to log in
before you can comment on or make changes to this bug.
Description
•