1438499 - Quitting Firefox doesn't suface the closing confirmation

Status: RESOLVED FIXED

(Firefox :: General, defect, P3)

Description

[Markus Jaritz [:designakt] (UX)]

Attachment: Firefox-Close-Behaviour.gif

By default closing Firefox with multiple tabs open, should give a warning... but doesn't always.

How to reproduced:
- open Firefox (new profile)
- open 2 or more tabs
- close Firefox by closing the Window
- Firefox will ask to confirm closing multiple tabs
- cancle
- close Firefox by clicking "Exit" in the Firefox Menu, 
  or by using the shortcut Ctrl+Shift+Q
- Firefox will close *without* confirm closing multiple tabs

expected result: 
Firefox would always confirm closing multiple Tabs.

actual result:
Sometimes asked for confirmation, sometimes not. Depending on how I close Firefox.

(see attachment for recording of that behaviour)

Observed on all current channels of Firefox, on Windows 10.

(To see if this is the intended behaviour I checked with phlsa, who was also suprised by this inconsistency.)

Comment 1

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

:shorlander, was this an intentional change?

Comment 2

[Stephen Horlander [:shorlander]]

(In reply to Emma Humphries, Bugmaster ☕️ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #1)
> :shorlander, was this an intentional change?

I don't think this is a recent change. I also can't remember where (or when) this behavior was defined :)

There have been different configurations WRT Session Restore over the years. It could be linked to the assumption that quitting Firefox is a recoverable action with Session Restore. But by that same rationale we also have a way to recover a closed Tab or Window.

We should be consistent with closing and data loss prevention. There are some nuances here though:

1) This Dialog's wording seems window bound, quitting Firefox (through the menu or with the short-cut) closes all tabs and windows, it would need to take that into account e.g. "You are about to close 10 windows containing 1,324 tabs. Do you want to continue?"

2) If this Dialog is triggered when quitting Firefox *but* you have Session Restore enabled, do we want to warn you?

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

Justin, feel free to change the priority if this seems more urgent.

Comment 4

[Justin Dolske [:Dolske]]

I'm pretty sure this is a dupe of a much older bug... Although I (mis?)remember it as being the opposite of what you saw -- close widget not confirming, but other menus did.

Comment 5

[:Gijs (he/him)]

Basically, bug 592822 turned off the quit warning dialog via an about:config pref. You can flip browser.showQuitWarning and you will get a dialog warning you about quit (and prompting you into using auto session restore). Please take a look at that dialog (it's not the same as 'closing multiple tabs'). bug 645338 covers having UI for the pref that surfaces it. There's also bug 1167998 and bug 550559, so note that if you flip the quit warning pref and then switch to having your tabs autorestore, we stop warning you (because we assume that you're happy just having the tabs reappear when you next start), and this makes people unhappy when they fat-finger a keyboard shortcut (for instance).

So our 'warn the user' story for quitting or closing windows is a giant mess. If UX can look carefully at all these bugs and come up with a plan for what we should do that works for:

- users who don't want any dialogs because they can just manually 'restore session' after restart
- users who expect dialogs when they destroy tabs with no auto session restore
- users who session restore but don't want to fat-finger ctrl(shift)q / cmd-q and lose time restoring their giant session
- multiple windows (don't want 5 instances of "you're closing multiple tabs" when hitting 'quit', even if all the warning prefs are on)
- aspirations some people have about making 'restore session' the default mixed in with performance concerns about doing that

then I think that would be useful. But we need a plan (and maybe user research), not whack-a-mole with the existing prefs/dialogs/bugs. Markus, can you drive that? Or is this just intended as a "huh, this is weird and we should 'just' fix it" bug? In which case it's probably a dupe of one of the aforementioned bugs, and we will probably go back to ignoring this for another few months/years, because it's not clear there's an obvious, simple, strict improvement to the status quo that won't inevitably mess things up for some segment of users.

Comment 6

[Markus Jaritz [:designakt] (UX)]

Attachment: current-browser-showQuitWarning-ui_off_by_default.png

This indeed started as "huh, this is weird and we should fix it"
And I still think this is the case. Not just because of bug 1167998, but for consistency of close behaviour.

Showing one "You are about to close [x] tabs( in [y] windows). Are you sure you want to continue?" will better solve for the cases described above as our current implementation does.

This would not touch people who have enabled session restore, and also not people that have opted out of this message. As these are quite different cases. But it will ensure consitency in how we close Firefox, and less people will end up with closing tabs they didn't want to close.

I agree that the bigger effored decribed by :Gijs might be nice to solve for all cases, but also think this is not needed to improve consistency for most users.

Attached is a screenshot of the old close dialog. I do not think we should ever re-introduce it. It is far to complex as to offer a simple choice on how to deal with closing every time.

Comment 7

[:Gijs (he/him)]

(In reply to Markus Jaritz [:designakt] (UX) from comment #6)
> Created attachment 8955546 [details]
> current-browser-showQuitWarning-ui_off_by_default.png
> 
> This indeed started as "huh, this is weird and we should fix it"
> And I still think this is the case. Not just because of bug 1167998, but for
> consistency of close behaviour.
> 
> Showing one "You are about to close [x] tabs( in [y] windows). Are you sure
> you want to continue?" will better solve for the cases described above as
> our current implementation does.
> 
> This would not touch people who have enabled session restore, and also not
> people that have opted out of this message.

Opted out of which message? There is probably a set of users that want the 'you're closing N tabs' warning when closing a window, but don't want it when using quit/exit, even if they don't use auto-sessionrestore. Are you saying we need to remove the existing 'save and quit' dialog and replace it with this new 'close X tabs in Y windows' message, and keep it behind a 'quit warning' pref but change the default to on instead of off? Or leave the default the same? Or something else?

FWIW, this would be a lot clearer if you laid out an exhaustive list of what should happen in different cases.

Comment 8

[Markus Jaritz [:designakt] (UX)]

(In reply to :Gijs (under the weather; responses will be slow) from comment #7)
> Opted out of which message? 

The closing confirmation message ("close X tabs") that people opt out of 
by choosing "show your windows and tabs from last time"

> There is probably a set of users that want the 'you're closing N tabs' 
> warning when closing a window, but don't want it when using quit/exit, 
> even if they don't use auto-sessionrestore. 

Probalby true for every bug &/or feature in Firefox. 
(reminds me of XKCDs CPU overheating comic)
We should however strive for simple consistent predictable behaviour, 
over different behaviour depending on how something is triggered.

> Are you saying we need to remove the existing 'save and quit' dialog and 
> replace it with this new 'close X tabs in Y windows' message, and keep it 
> behind a 'quit warning' pref but change the default to on instead of off?
> Or leave the default the same? Or something else?

That could be a way to achive what I see as the consistent behaviour:
Have the same message, no matter how one closes the browser, 
until they opt out of that message.
I saw the solution to that more as, add " in [y] windows" to the current 
"close X tabs"-message if needed, and show that once on any way to close 
the browser, not just on closing the last window.

But how to implement it is your expertise.

> FWIW, this would be a lot clearer if you laid out an exhaustive list of what
> should happen in different cases.

Close browser via closing last tab                           -> close
Close browser with multiple tabs via closing the last window -> Confirm close
Close browser with multiple tabs via closing shortcut        -> Confirm close
Close browser with multiple tabs via Exit in Firefox Menu    -> Confirm close

Close browser after opting out of that confirmation message  -> close


Confirm Close Message:
Title: Confirm Close
Copy: You are about to close X tabs (in Y windows). 
      Are you sure you want to continue?
  [x] Warn me when I attempt to close multiple tabs
      Close tabs    Cancel

(show dialog once, no matter how many windows are being closed)

Does that clear things up for you Gijs? If not I am happy to vidyo-chat.

Comment 9

[Sören Hentzschel]

(In reply to Markus Jaritz [:designakt] (UX) from comment #8)
> The closing confirmation message ("close X tabs") that people opt out of 
> by choosing "show your windows and tabs from last time"

(In reply to Markus Jaritz [:designakt] (UX) from comment #8)
> Close browser after opting out of that confirmation message  -> close

If I may express my opinion on it… :) For me that's a big misinterpretation of my real intention as user. I don't see the session restore as opt out of the confirmation dialog at all and it makes me angry every time I accidentally close Firefox because Cmd + Q is left of Cmd + W and use this shortcut a few hundred times per day for closing tabs. It happens too often that I use the wrong shortcut and it's even with loading the tabs on demand no fun.

You say you want "simple consistent predictable behaviour" - that's great because I want the same! :) But for me this means that there *is* a confirmation dialog even if session restore is enabled. I don't see this correlation as "predictable" at all.

Comment 10

[Markus Jaritz [:designakt] (UX)]

(In reply to Sören Hentzschel from comment #9)
> I don't see the session restore as opt out of the confirmation dialog at 
> all and it makes me angry every time I accidentally close Firefox because 
> Cmd + Q is left of Cmd + W and use this shortcut a few hundred times per 
> day for closing tabs. 

I mentioned this behaviour here as this is how we currently do it. 
I did not want to say it is right or wrong, I just states what is.
This bug does not affect that behavour.

Please file a seperate bug for your question on wheather or not 
session restore and close confirmation should be separated.

Comment 11

[:Gijs (he/him)]

(In reply to Markus Jaritz [:designakt] (UX) from comment #8)
> (In reply to :Gijs (under the weather; responses will be slow) from comment
> #7)
> > Opted out of which message? 
> 
> The closing confirmation message ("close X tabs") that people opt out of 
> by choosing "show your windows and tabs from last time"

This is confusing, because later on you talk about opting out via the checkbox in this warning dialog, which is not the same thing...

> > There is probably a set of users that want the 'you're closing N tabs' 
> > warning when closing a window, but don't want it when using quit/exit, 
> > even if they don't use auto-sessionrestore. 
> 
> Probalby true for every bug &/or feature in Firefox. 
> (reminds me of XKCDs CPU overheating comic)

I don't think accidental dataloss by shortcut-fatfinger is at all comparable to that comic.

> > FWIW, this would be a lot clearer if you laid out an exhaustive list of what
> > should happen in different cases.
> 
> Close browser via closing last tab                           -> close
> Close browser with multiple tabs via closing the last window -> Confirm close
> Close browser with multiple tabs via closing shortcut        -> Confirm close
> Close browser with multiple tabs via Exit in Firefox Menu    -> Confirm close

What happens if I close the window, use a shortcut or Exit, and there is only 1 tab open?

> Close browser after opting out of that confirmation message  -> close

So specifically, does the checkbox in all these dialogs map to a single preference? I assume you want the answer to be 'yes', but it's not explicit.

For the exit case and session restore, what happens if I:

Close browser with multiple tabs via Exit / cmd-q / ctrl-(shift-)q, with:

> auto-sessionrestore on, while having opted out in the dialog --> close
> auto-sessionrestore on, not having opted out using the checkbox in the dialog --> ??
> auto-sessionrestore off, <idem> --> ??
> auto-sessionrestore off, having opted out using the checkbox in the dialog --> close (I think ?)


> If not I am happy to vidyo-chat.

I'd like to continue on bugzilla so there is a record of the considerations that led to re-evaluating behaviour, because this is a super-contentious topic and I have no interest in later having to rationalize any change in behaviour post-facto based on my recollections of a vidyo discussion that happened 3 months before. :-)

Comment 12

[Markus Jaritz [:designakt] (UX)]

(In reply to :Gijs (under the weather; responses will be slow) from comment #11)
> > > There is probably a set of users that want the 'you're closing N tabs' 
> > > warning when closing a window, but don't want it when using quit/exit, 
> > > even if they don't use auto-sessionrestore. 
> > 
> > Probalby true for every bug &/or feature in Firefox. 
> > (reminds me of XKCDs CPU overheating comic)
> 
> I don't think accidental dataloss by shortcut-fatfinger is at all comparable
> to that comic.

The case you described sounded to me like the exact oposit of the fatfinger-case.
(As I replied to Sören, I think the fatfinger-case should we addressed, but I think it is a seperate issue.)

Are you on Mac? We might be experiencing different behaviour on shortcut.
For me on Win, Ctrl-Q does nothing, Ctrl-W closes a tab, and Ctrl-Shift-Q closes the browser.


> What happens if I close the window, use a shortcut or Exit, and there is
> only 1 tab open?

Same that happens now. It closes the browser. (without confirmation):
Close browser with one tab open via any possible way         -> close


> > Close browser after opting out of that confirmation message  -> close
> 
> So specifically, does the checkbox in all these dialogs map to a single
> preference? I assume you want the answer to be 'yes', but it's not explicit.

I see this as ONE dialog, that is triggered in different ways... 
So unchecking the checkbox once, should disable the dialog for all ways to trigger it.
I guess that might translate into one preference...


> For the exit case and session restore, what happens if I:
> 
> Close browser with multiple tabs via Exit / cmd-q / ctrl-(shift-)q, with:

> > auto-sessionrestore on, while having opted out in the dialog --> close

> > auto-sessionrestore on, not having opted out using the checkbox in the dialog --> close
This is the fatfinger-case we mentioned before... this bug would not change the behaviour on that case. 
Improving the behaviour for that case should be a seperate bug.

> > auto-sessionrestore off, not having opted out using the checkbox in the dialog --> Confirm close
> > auto-sessionrestore off, having opted out using the checkbox in the dialog --> close


I see there there are may aspects of getting the right close behaviour for all cases. I would hope for this to only improve some cases... on not evolve into one thing that tries fixing everything. That is why I ask for seperating the fatfinger-case. (it is an important case - at least on mac - but not affected by my proposal for this bug.)

Thanks for the quick follow-up... and hope you feel better soon.

I hope to have answered all your questions understandly. If you confirm that, I can summarize what we agree on.

Comment 13

[:Gijs (he/him)]

Attachment: Bug 1438499 - show 'close multiple tabs' warning dialog when quitting,

Review commit: https://reviewboard.mozilla.org/r/250840/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250840/

Comment 14

[:Gijs (he/him)]

Trypush: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6cc78822b53508ab7a69aab38495098b43ce7f77

Markus, can you check if this build has the behavior you expect?


Separately, I'm removing the showQuitWarning pref because its functionality is now redundant with the browser.tabs.warnOnClose pref, and there is already a separate hidden "don't prompt me when quitting" pref, so it seems there's no point to keep it. It seems gecko-driver and marionette.js include a reference to this pref setting it to false, which is the default anyway. Last time I tried to remove a pref value in marionette I got told off because apparently things need to work on previous versions of Firefox or something, so now I don't know if I'm supposed to remove them here. :whimboo, can you help?

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to :Gijs (he/him) from comment #14)
> Separately, I'm removing the showQuitWarning pref because its functionality
> is now redundant with the browser.tabs.warnOnClose pref, and there is
> already a separate hidden "don't prompt me when quitting" pref, so it seems
> there's no point to keep it. It seems gecko-driver and marionette.js include
> a reference to this pref setting it to false, which is the default anyway.

Which preference are you referring to here? Is it `browser.tabs.warnOnClose`? I ask because when I check `firefox.js` the preference is set to `true` by default:

https://dxr.mozilla.org/mozilla-central/rev/75a32b57132f8cba42779555662a057a0416a313/browser/app/profile/firefox.js#456

Do I miss something?

> Last time I tried to remove a pref value in marionette I got told off
> because apparently things need to work on previous versions of Firefox or
> something, so now I don't know if I'm supposed to remove them here.
> :whimboo, can you help?

Thanks for getting back to us!

Comment 16

[:Gijs (he/him)]

Comment on attachment 8985191 [details]
Bug 1438499 - show 'close multiple tabs' warning dialog when quitting,

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/250840/diff/1-2/

Comment 17

[Markus Jaritz [:designakt] (UX)]

Works with one window... but does not produce a dialog if there are multiple windows.
Other then that it is what I expected. And the update you showed works perfectly. Thanks.

Comment 18

[:Gijs (he/him)]

(In reply to Henrik Skupin (:whimboo) from comment #15)
> (In reply to :Gijs (he/him) from comment #14)
> > Separately, I'm removing the showQuitWarning pref because its functionality
> > is now redundant with the browser.tabs.warnOnClose pref, and there is
> > already a separate hidden "don't prompt me when quitting" pref, so it seems
> > there's no point to keep it. It seems gecko-driver and marionette.js include
> > a reference to this pref setting it to false, which is the default anyway.
> 
> Which preference are you referring to here? Is it
> `browser.tabs.warnOnClose`? I ask because when I check `firefox.js` the
> preference is set to `true` by default:
> 
> https://dxr.mozilla.org/mozilla-central/rev/
> 75a32b57132f8cba42779555662a057a0416a313/browser/app/profile/firefox.js#456
> 
> Do I miss something?

No, sorry, I meant the showQuitWarning pref:

https://dxr.mozilla.org/mozilla-central/search?q=showquitwarning&=mozilla-central

https://dxr.mozilla.org/mozilla-central/rev/75a32b57132f8cba42779555662a057a0416a313/browser/app/profile/firefox.js#276
https://dxr.mozilla.org/mozilla-central/rev/75a32b57132f8cba42779555662a057a0416a313/testing/geckodriver/src/prefs.rs#40
https://dxr.mozilla.org/mozilla-central/rev/75a32b57132f8cba42779555662a057a0416a313/testing/marionette/components/marionette.js#112


(In reply to Markus Jaritz [:designakt] (UX) from comment #17)
> Works with one window... but does not produce a dialog if there are multiple
> windows.
> Other then that it is what I expected. And the update you showed works
> perfectly. Thanks.

Great! To be clear, I pushed this update just now, so Jared, the review should be up-to-date. :-)

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to :Gijs (he/him) from comment #18)
> No, sorry, I meant the showQuitWarning pref:

Ok, you are safe to remove it from both of the files. Don't worry about the comment with minimum version of 61. I added that recently because I added the pref to marionette.js (see bug 1466658). It's indeed good to see that we can get rid of it. Update your patch and ask me for review.

Comment 20

[:Gijs (he/him)]

Comment on attachment 8985191 [details]
Bug 1438499 - show 'close multiple tabs' warning dialog when quitting,

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/250840/diff/2-3/

Comment 21

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8985191 [details]
Bug 1438499 - show 'close multiple tabs' warning dialog when quitting,

https://reviewboard.mozilla.org/r/250840/#review257978

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 8985191 [details]
Bug 1438499 - show 'close multiple tabs' warning dialog when quitting,

https://reviewboard.mozilla.org/r/250840/#review258298

::: testing/geckodriver/src/prefs.rs
(Diff revision 3)
>          // Skip check for default browser on startup
>          ("browser.shell.checkDefaultBrowser", Pref::new(false)),
>  
> -        // Do not warn when quitting with multiple tabs
> -        // TODO: Remove once minimum supported Firefox release is 61.
> -        ("browser.showQuitWarning", Pref::new(false)),

This doesn't compile. You will also have to decrease the count above.

Comment 23

[:Gijs (he/him)]

(In reply to Henrik Skupin (:whimboo) from comment #22)
> Comment on attachment 8985191 [details]
> Bug 1438499 - show 'close multiple tabs' warning dialog when quitting,
> 
> https://reviewboard.mozilla.org/r/250840/#review258298
> 
> ::: testing/geckodriver/src/prefs.rs
> (Diff revision 3)
> >          // Skip check for default browser on startup
> >          ("browser.shell.checkDefaultBrowser", Pref::new(false)),
> >  
> > -        // Do not warn when quitting with multiple tabs
> > -        // TODO: Remove once minimum supported Firefox release is 61.
> > -        ("browser.showQuitWarning", Pref::new(false)),
> 
> This doesn't compile. You will also have to decrease the count above.

Is there a bug on file to make this less footgunny? Manually keeping track of the length of this array is pretty dumb - surely there's a better way to do this in rust?

(I didn't notice this, for obvious reasons, and because in an artifact build "doesn't compile" doesn't exist.)

Comment 24

[:Gijs (he/him)]

Comment on attachment 8985191 [details]
Bug 1438499 - show 'close multiple tabs' warning dialog when quitting,

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/250840/diff/3-4/

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to :Gijs (he/him) from comment #23)
> > ::: testing/geckodriver/src/prefs.rs
> > (Diff revision 3)
> > >          // Skip check for default browser on startup
> > >          ("browser.shell.checkDefaultBrowser", Pref::new(false)),
> > >  
> > > -        // Do not warn when quitting with multiple tabs
> > > -        // TODO: Remove once minimum supported Firefox release is 61.
> > > -        ("browser.showQuitWarning", Pref::new(false)),
> > 
> > This doesn't compile. You will also have to decrease the count above.
> 
> Is there a bug on file to make this less footgunny? Manually keeping track
> of the length of this array is pretty dumb - surely there's a better way to
> do this in rust?
> 
> (I didn't notice this, for obvious reasons, and because in an artifact build
> "doesn't compile" doesn't exist.)

Let me forward this to Andreas. Maybe there is another data type we could make use of.

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 8985191 [details]
Bug 1438499 - show 'close multiple tabs' warning dialog when quitting,

https://reviewboard.mozilla.org/r/250840/#review258366

Comment 27

[Andreas Tolfsen ❲:ato❳]

(In reply to :Gijs (he/him) from comment #23)

> Is there a bug on file to make this less footgunny? Manually
> keeping track of the length of this array is pretty dumb - surely
> there's a better way to do this in rust?

It is probably possible to use a Vector or a HashMap at a slightly
higher cost of initialisation.

The vec!() macro is expanded at build time which might alleviate the
cost of not knowing the initial size of the vector.

> (I didn't notice this, for obvious reasons, and because in an
> artifact build "doesn't compile" doesn't exist.)

Sorry about this. geckodriver is compiled, so you need a compile
environment to work with it.

Comment 28

[:Gijs (he/him)]

(In reply to Andreas Tolfsen 「:ato」 from comment #27)
> (In reply to :Gijs (he/him) from comment #23)
> 
> > Is there a bug on file to make this less footgunny? Manually
> > keeping track of the length of this array is pretty dumb - surely
> > there's a better way to do this in rust?
> 
> It is probably possible to use a Vector or a HashMap at a slightly
> higher cost of initialisation.
> 
> The vec!() macro is expanded at build time which might alleviate the
> cost of not knowing the initial size of the vector.

I filed bug 1470100 and will have a look if I can write a patch.\


I'm going to hold off landing this because there are string changes and we're soft-frozen for merge next week. I'll land it then.

Comment 29

[:Gijs (he/him)]

Comment on attachment 8985191 [details]
Bug 1438499 - show 'close multiple tabs' warning dialog when quitting,

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/250840/diff/4-5/

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7e18d20c263f
show 'close multiple tabs' warning dialog when quitting, r=jaws,whimboo

Comment 31

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/7e18d20c263f

Comment 32

[Itiel]

Is there a follow-up plan here to add a warning when closing Firefox even with session restore on?
Sometimes I accidentally click the X button and don't want the browser to close (even though I know everything will be restored on the next launch), so this confirmation gives me the protection I need.

My user story:
I had to use mozregression to get to this bug as I treated this an issue.
I had all browser.showQuitWarning, browser.tabs.warnOnClose and browser.warnOnQuit set to true and session restore was off (because, if I already see this message every time and by deafult I select the Save option, I don't need to turn on session restore). I was used to see the Save and Quit dialog whenever I clicked the X button, so now I almost lost all 300+ open tabs if I had pressed enter (out of habit).
Now I was forced to enable the session restore option but I'm still missing the confirmation dialog.

If there's no plan to add a warning when session restore is on, can you please at least show that as warning in the release notes? I may have been lucky here but others may be not.

Comment 33

[:Gijs (he/him)]

(In reply to Itiel from comment #32)
> Is there a follow-up plan here to add a warning when closing Firefox even
> with session restore on?

--> Markus.

Comment 34

[Markus Jaritz [:designakt] (UX)]

(In reply to Itiel from comment #32)
> Is there a follow-up plan here to add a warning when closing Firefox even
> with session restore on?

In short: no plan for that. 

Reason: Firefox saves everything, 
so there is no risk of data-loss, 
and therefor no need to warn.


(In reply to Itiel from comment #32)
> I had all browser.showQuitWarning, browser.tabs.warnOnClose and
> browser.warnOnQuit set to true and session restore was off (because, if I
> already see this message every time and by deafult I select the Save option,
> I don't need to turn on session restore). I was used to see the Save and
> Quit dialog whenever I clicked the X button, so now I almost lost all 300+
> open tabs if I had pressed enter (out of habit).

Sounds like your habit established around always saving as default.
So it seams enabling session restore does come with a big impact for you.

This suggests that we should enable session restore for people 
that have this pref on, to ensure they will not lose open tabs.
(I would be curious what portion of our user base that is...)


> If there's no plan to add a warning when session restore is on, can you
> please at least show that as warning in the release notes? I may have been
> lucky here but others may be not.

Mentioning the removal in release notes is a good point. We should do that.

Comment 35

[Sören Hentzschel]

(In reply to Markus Jaritz [:designakt] (UX) from comment #34)
> In short: no plan for that. 
> 
> Reason: Firefox saves everything, 
> so there is no risk of data-loss, 
> and therefor no need to warn.

I couldn't disagree more and want to refer to comment #9 where I already explained why I think so. It's one of the biggest UX weaknesses of Firefox for me. :-(

I have more than hundred tabs open and no, session restore does not save everything, that's not true. For example the state of the developer tools is not restored and I have to re-enter all HttpAuth usernames and passwords. Since I am one of the millions of web developers I work a lot with the developer tools and there are a few websites opened in my browser which are behind a HttpAuth access protection. The HttpAuth thing is no data-loss, but annoying. But losing the state of the developer tools *can* be a data-loss.

Comment 36

[Markus Jaritz [:designakt] (UX)]

Thanks for bringing up those cases. Especially the Dev Tool case seams very relevant.

However, this is going far beyond the scope of this bug though, which is:
> Closing Firefox through menu or shortcut, does not surface the closing confirmation

Can you please file this weakness as a separate bug. Thanks.

Comment 37

[:Gijs (he/him)]

Release Note Request (optional, but appreciated)
[Why is this notable]: Changes long-standing quit behaviors
[Affects Firefox for Android]: no
[Suggested wording]: Firefox now warns about having multiple windows/tabs open when quitting.
[Links (documentation, blog post, etc)]: n/a

(In reply to Markus Jaritz [:designakt] (UX) from comment #36)
> Thanks for bringing up those cases. Especially the Dev Tool case seams very
> relevant.
> 
> However, this is going far beyond the scope of this bug though, which is:
> > Closing Firefox through menu or shortcut, does not surface the closing confirmation
> 
> Can you please file this weakness as a separate bug. Thanks.

While on the one hand I agree that this bug fixes a particular problem that isn't the sessionstore one, the summary of this bug contains what sounds like the same problem people are pointing out: you quit Firefox, and you get no prompt, but you want one. It's just happening to people using sessionstore under slightly different circumstances to the one in comment #0.

We already have a bunch of bugs about the sessionstore issue, as well as people accidentally hitting the shortcut key on mac/linux (see comment #5). I don't think we need another one - the question is how to address the issue...

Comment 38

[Markus Jaritz [:designakt] (UX)]

(In reply to :Gijs (he/him) from comment #37)
> We already have a bunch of bugs about the sessionstore issue, as well as
> people accidentally hitting the shortcut key on mac/linux (see comment #5).
> I don't think we need another one - the question is how to address the
> issue...

Thanks for pointing out those 2 bugs again, they sound like a good description of the problem described by Itiel and Sören.
I asked a college to look into Bug 550559 (and also into Bug 1167998), and reach out to another college working on DevTools for them to particularly consider the close case for their users, as it seams to have more unpleasant effects on them.

Comment 39

[Mohammad Maruf Rahman]

I have reproduced this bug with Nightly 60.0a1 (2018-02-15) on Windows 10, 64 Bit!
This bug's fix is verified with latest Nightly!

Build ID 	20180710100040
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Comment 40

[jcpereira]

I updated to the latest nightly (i was on a 1 month old build).

I don't have "restore previous session" selected because i don´t want every session restored.

I had "browser.showquitwarning" set to true. When i had more than one tab and close Firefox, a dialog ask me if i wanted to save the session.

With the latest build the dialog don´t have this option.

is this a bug? How can i save a particular session with "restore previous session" disabled?

Comment 41

[:Gijs (he/him)]

(In reply to jcpereira from comment #40)
> I updated to the latest nightly (i was on a 1 month old build).
> 
> I don't have "restore previous session" selected because i don´t want every
> session restored.
> 
> I had "browser.showquitwarning" set to true. When i had more than one tab
> and close Firefox, a dialog ask me if i wanted to save the session.
> 
> With the latest build the dialog don´t have this option.
> 
> is this a bug? How can i save a particular session with "restore previous
> session" disabled?

Once you start Firefox again, you can use the hamburger menu (or toplevel macOS History menu if you're on a mac, or in the "old-style" menu bar on Windows/Linux, if you enable it) and click "Restore previous session".

Comment 42

[jcpereira]

(In reply to :Gijs (he/him) from comment #41)
> (In reply to jcpereira from comment #40)
> > I updated to the latest nightly (i was on a 1 month old build).
> > 
> > I don't have "restore previous session" selected because i don´t want every
> > session restored.
> > 
> > I had "browser.showquitwarning" set to true. When i had more than one tab
> > and close Firefox, a dialog ask me if i wanted to save the session.
> > 
> > With the latest build the dialog don´t have this option.
> > 
> > is this a bug? How can i save a particular session with "restore previous
> > session" disabled?
> 
> Once you start Firefox again, you can use the hamburger menu (or toplevel
> macOS History menu if you're on a mac, or in the "old-style" menu bar on
> Windows/Linux, if you enable it) and click "Restore previous session".

That worked, thanks.

I was used to the old behavior. It worked better for me.

Usually when i ´m at work and wanted to save a session for the next day/week, i´m used to select save the session in the option “save and quit”. In the next/week day when i open Firefox it was restored.

With this behavior  i will probably forgot the next day/week that i have a session that i want to resume.

Comment 43

[:Gijs (he/him)]

(In reply to jcpereira from comment #42)
> (In reply to :Gijs (he/him) from comment #41)
> > (In reply to jcpereira from comment #40)
> > > I updated to the latest nightly (i was on a 1 month old build).
> > > 
> > > I don't have "restore previous session" selected because i don´t want every
> > > session restored.
> > > 
> > > I had "browser.showquitwarning" set to true. When i had more than one tab
> > > and close Firefox, a dialog ask me if i wanted to save the session.
> > > 
> > > With the latest build the dialog don´t have this option.
> > > 
> > > is this a bug? How can i save a particular session with "restore previous
> > > session" disabled?
> > 
> > Once you start Firefox again, you can use the hamburger menu (or toplevel
> > macOS History menu if you're on a mac, or in the "old-style" menu bar on
> > Windows/Linux, if you enable it) and click "Restore previous session".
> 
> That worked, thanks.
> 
> I was used to the old behavior. It worked better for me.
> 
> Usually when i ´m at work and wanted to save a session for the next
> day/week, i´m used to select save the session in the option “save and quit”.
> In the next/week day when i open Firefox it was restored.
> 
> With this behavior  i will probably forgot the next day/week that i have a
> session that i want to resume.

The alternative would be to turn on automatic session restore and then just close the session if you find out you don't want it the next week... Unless you use multiple windows, you can just open a new tab and then right click it and pick "close other tabs".


Anyway, needinfo for UX to see if they want to change this some more to accommodate your usecase...

Comment 44

[saturos.ice]

(In reply to :Gijs (he/him) from comment #43)
[shorten this a bit]
> 
> The alternative would be to turn on automatic session restore and then just
> close the session if you find out you don't want it the next week... Unless
> you use multiple windows, you can just open a new tab and then right click
> it and pick "close other tabs".
> 
> 
> Anyway, needinfo for UX to see if they want to change this some more to
> accommodate your usecase...

I am really sorry, but imho the alternative would have been to just restore stoneage-FF 3.x behavior (not too sure about the version but absolutely sure it was there once), which I cannot understand why it ever got changed anyway...  Just ask for Save&Quit, Quit or Cancel everytime. What is the sense in even distinguishing between these messages, i.e. hiding the Save&Quit option by default? The only valid reason I see is when having multiple open windows and closing one, you should not be asked to Save&Quit, but only for confirmation or cancellation. However seemingly this warnonquit has been mistakingly interchanged with showquitwarning. It is probably the insufficient naming of these two options that should be blamed for this; their difference is very real but not described effectively.

My surfing behavior always was to start fresh but sometimes you get to a point where you want to save, what you have now as has been pointed out already. In that case it is the most convenient way, imho, to just hit Save&Quit, instead of having to mess around with hamburgers or other (often changing...) menus.


So in essence...
- I totally agree with the initial bug, that no matter how a closing action is made, the/a message should be displayed (or not -> would have been the real purpose of warnonquit, I think)
- Removing showquitwarning imho had nothing to do with this issue and should be kept at least (this is my user-view - might be there was a technical reason I did not get in the above log)
- When there are multiple windows and one is to be closed the confirmation dialogue should be displayed
- When there is a single window and "always restore previous session" is off, it seems reasonable to show the showquitwarning dialogue instead of warnonquit's simple confirmation dialogue
- When there is a single window and "always restore previous session" is on, for convenience and according to the warnonclose option, a confirmation dialogue should be displayed or not
-> probably worth a separate feature request: having a second option next to "always restore previous session" to control warnonquit through a ui setting, as probably less confident/experienced users would not go beyond about:configs confirmation page...

And lastly more of a thought or question I am curious about: Does it only seem so or is it a fact that "restore previous session" works else than showquitwarning's saved session? If that is the case, this might be one more thing to tidy up...

Just 2ct from a user :-)

Comment 45

[saturos.ice]

(In reply to saturos.ice from comment #44)
> (In reply to :Gijs (he/him) from comment #43)
> [shorten this a bit]
> > 
> > The alternative would be to turn on automatic session restore and then just
> > close the session if you find out you don't want it the next week... Unless
> > you use multiple windows, you can just open a new tab and then right click
> > it and pick "close other tabs".
> > 
> > 
> > Anyway, needinfo for UX to see if they want to change this some more to
> > accommodate your usecase...
> 
> I am really sorry, but imho the alternative would have been to just restore
> stoneage-FF 3.x behavior (not too sure about the version but absolutely sure
> it was there once), which I cannot understand why it ever got changed
> anyway...  Just ask for Save&Quit, Quit or Cancel everytime. What is the
> sense in even distinguishing between these messages, i.e. hiding the
> Save&Quit option by default? The only valid reason I see is when having
> multiple open windows and closing one, you should not be asked to Save&Quit,
> but only for confirmation or cancellation. However seemingly this warnonquit
> has been mistakingly interchanged with showquitwarning. It is probably the
> insufficient naming of these two options that should be blamed for this;
> their difference is very real but not described effectively.
> 
> My surfing behavior always was to start fresh but sometimes you get to a
> point where you want to save, what you have now as has been pointed out
> already. In that case it is the most convenient way, imho, to just hit
> Save&Quit, instead of having to mess around with hamburgers or other (often
> changing...) menus.
> 
> 
> So in essence...
> - I totally agree with the initial bug, that no matter how a closing action
> is made, the/a message should be displayed (or not -> would have been the
> real purpose of warnonquit, I think)
> - Removing showquitwarning imho had nothing to do with this issue and should
> be kept at least (this is my user-view - might be there was a technical
> reason I did not get in the above log)
> - When there are multiple windows and one is to be closed the confirmation
> dialogue should be displayed
> - When there is a single window and "always restore previous session" is
> off, it seems reasonable to show the showquitwarning dialogue instead of
> warnonquit's simple confirmation dialogue
> - When there is a single window and "always restore previous session" is on,
> for convenience and according to the warnonclose option, a confirmation
> dialogue should be displayed or not
> -> probably worth a separate feature request: having a second option next to
> "always restore previous session" to control warnonquit through a ui
> setting, as probably less confident/experienced users would not go beyond
> about:configs confirmation page...
> 
> And lastly more of a thought or question I am curious about: Does it only
> seem so or is it a fact that "restore previous session" works else than
> showquitwarning's saved session? If that is the case, this might be one more
> thing to tidy up...
> 
> Just 2ct from a user :-)

Mistakes were made...
- When there is a single window and "always restore previous session" is on, for convenience and according to the warnonclose option, a confirmation dialogue should be displayed or not

This should really be based on warnonquit, NOT warnonclose, which is a tabs setting..

Comment 46

[Markus Jaritz [:designakt] (UX)]

(In reply to :Gijs (he/him) from comment #43)
> (In reply to jcpereira from comment #42)
> > (In reply to :Gijs (he/him) from comment #41)
> > > (In reply to jcpereira from comment #40)
> > > > I updated to the latest nightly (i was on a 1 month old build).
> > > > 
> > > > I don't have "restore previous session" selected because i don´t want every
> > > > session restored.
> > > > 
> > > > I had "browser.showquitwarning" set to true. When i had more than one tab
> > > > and close Firefox, a dialog ask me if i wanted to save the session.
> > > > 
> > > > With the latest build the dialog don´t have this option.
> > > > 
> > > > is this a bug? How can i save a particular session with "restore previous
> > > > session" disabled?
> > > 
> > > Once you start Firefox again, you can use the hamburger menu (or toplevel
> > > macOS History menu if you're on a mac, or in the "old-style" menu bar on
> > > Windows/Linux, if you enable it) and click "Restore previous session".
> > 
> > That worked, thanks.
> > 
> > I was used to the old behavior. It worked better for me.
> > 
> > Usually when i ´m at work and wanted to save a session for the next
> > day/week, i´m used to select save the session in the option “save and quit”.
> > In the next/week day when i open Firefox it was restored.
> > 
> > With this behavior  i will probably forgot the next day/week that i have a
> > session that i want to resume.
> 
> The alternative would be to turn on automatic session restore and then just
> close the session if you find out you don't want it the next week... Unless
> you use multiple windows, you can just open a new tab and then right click
> it and pick "close other tabs".
> 
> 
> Anyway, needinfo for UX to see if they want to change this some more to
> accommodate your usecase...

Or another alternative would be using session restore, 
and closing all tabs that one does not want restored, 
before closing Firefox at the end of the day.

Thanks for the needinfo, but I think that use-case is sufficiently covered.

Comment 47

[Kestrel]

browser.showQuitWarning was a good fail-safe to avoid data loss but now that it has been removed a suitable replacement is needed, hopefully Bug 550559 can be expedited to avoid a regression.

Comment 48

[:Gijs (he/him)]

Pascal, can you restore the relnote flag please?

Comment 49

[Pascal Chevrel:pascalc (PTO until April 26)]

Done, thanks for noticing.

Comment 51

[LepidopTERA]

I read through this bug in its entirety and I'm left struck as to how it was handled.  I spent a couple hours last night trying to figure out why I was no longer being given the option to "Save and Quit" because there was nothing about it in the release notes, despite this being flagged for a release note.

>Firefox now warns about having multiple windows and tabs open when quitting from the main menu

Shouldn't this follow with something along the lines of:

>"The "Save and Quit" feature has been removed.  Users are encouraged to restore their session by ticking the box for "Restore previous session" in the General -> Startup options or by using "Restore Previous Session" in the main menu.

Also, this was listed as "new", but shouldn't it have been listed as "fixed"?  We can see from here that this has worked in the past:

http://forums.mozillazine.org/viewtopic.php?f=7&t=3040765 (2018)
https://support.mozilla.org/en-US/questions/1071575 (2015)

I see it stated the "browser.showQuitWarning" preference was removed; for just a certain subset of users?  I still have it and was more than a little confused when I would toggle it back-and-forth between true and false and nothing would happen.  If I had toggled it at some point in the past, does that mean it would hang around after an update?  I see it in my "prefs.js" file.  If that's the case, shouldn't that somehow be overridden if it's not functional?

(In reply to Markus Jaritz [:designakt] (UX) from comment #34)
> (In reply to Itiel from comment #32)
> > Is there a follow-up plan here to add a warning when closing Firefox even
> > with session restore on?
> 
> In short: no plan for that. 
> 
> Reason: Firefox saves everything, 
> so there is no risk of data-loss, 
> and therefor no need to warn.

It does when it works.  Just look at all the bugs for the Session Restore component, especially bug 1330635.  That said, I realize where that is a separate issue entirely and will behave the same no matter whether the user uses "Save and Quit" or "Restore Previous Session".

However, from a user experience standpoint, this wasn't good.  We can see where this negatively affected users in just this small sampling:

https://www.reddit.com/r/firefox/comments/9e9nbk/what_happened_to_save_quit_button/
https://www.reddit.com/r/firefox/comments/8u0t9y/firefox_630a1_no_longer_shows_save_tabs_and_quit/

It's jarring to toggle "Restore previous session" on startup and have browser browser close without any confirmation.

There was a lot of ground to cover here, so I hope this doesn't feel disjointed.  I want to conclude stating that I am a layman among professionals, so my intent is purely to humbly provide my experience as a longtime user who has experienced many changes in Firefox without significant issue.

Comment 52

[trinaldi]

Thanks, @LepidopTERA.

I'm the OP from the first post from Reddit you've mentioned.

It is *very* frustrating to have something taken out, especially like you said 'because there was nothing about it in the release notes'

Comment 53

[Pascal Chevrel:pascalc (PTO until April 26)]

(In reply to trinaldi from comment #52)
> Thanks, @LepidopTERA.
> 
> I'm the OP from the first post from Reddit you've mentioned.
> 
> It is *very* frustrating to have something taken out, especially like you
> said 'because there was nothing about it in the release notes'

The missing note is totally my fault as I thought I had it added in our tools and it wasn't the case, sorry about it :(

Comment 54

[:Gijs (he/him)]

(In reply to LepidopTERA from comment #51)
> I read through this bug in its entirety and I'm left struck as to how it was
> handled.  I spent a couple hours last night trying to figure out why I was
> no longer being given the option to "Save and Quit" because there was
> nothing about it in the release notes, despite this being flagged for a
> release note.
> 
> >Firefox now warns about having multiple windows and tabs open when quitting from the main menu
> 
> Shouldn't this follow with something along the lines of:
> 
> >"The "Save and Quit" feature has been removed.  Users are encouraged to restore their session by ticking the box for "Restore previous session" in the General -> Startup options or by using "Restore Previous Session" in the main menu.

Yes. Perhaps not as expansive as this, but I should probably have suggested mentioning the dialog. My suggestion in comment 37 was too brief, and that's on me.

Pascal: can you update the relnote to include something as suggested by LepidopTERA? Maybe "You can restore your session by ...", rather than "Users are encouraged to..." to make it less impersonal.

> I see it stated the "browser.showQuitWarning" preference was removed; for
> just a certain subset of users?  I still have it and was more than a little
> confused when I would toggle it back-and-forth between true and false and
> nothing would happen.  If I had toggled it at some point in the past, does
> that mean it would hang around after an update?

Yes. Any non-default values of prefs are stored in prefs.js . In this case, because the pref was removed, *any* value is non-default, and will continue to be stored indefinitely. You can remove it from prefs.js manually, or in about:config, right-click and choose "reset". Either way, the value being there will no longer have any effect.

>  I see it in my "prefs.js"
> file.  If that's the case, shouldn't that somehow be overridden if it's not
> functional?

We're not very consistent about removing custom values for preferences which are no longer supported from users' profiles, as their presence doesn't actually cause any harm, and removing them can lead to unexpected behavior when switching between builds/versions. This is something we're addressing, orthogonal to this issue, and may result in us being more aggressive in removing these types of "dead" prefs/data -- though this also has downsides. Some recent discussion happened here: https://groups.google.com/forum/?fromgroups=&hl=en#!topic/firefox-dev/wDjPSU9OWq8 .

This pref is a bit of a strange case because it was never exposed, so anyone running into this would be checking about:config, rather than the preferences/options. Normally, this type of removal affects prefs that had UI, in which case the UI is gone and it's clear that something was removed (even if we left the internal pref state and you could find it in about:config if you went looking).

Comment 55

[Pascal Chevrel:pascalc (PTO until April 26)]

(In reply to :Gijs (he/him) from comment #54)
> Pascal: can you update the relnote to include something as suggested by
> LepidopTERA? Maybe "You can restore your session by ...", rather than "Users
> are encouraged to..." to make it less impersonal.

Updated

Comment 56

[2fuzzy]

Is warning message about closing multiple tabs also removed when Restore previous session activated?

Comment 57

[LepidopTERA]

Thank you all for your responses.  You've helped me understand more about some of the things that occurred here.

Gijs, without going too far off the original topic of this bug, you're saying all removed preferences end up in prefs.js?  Even though it's still in about:config, how is it recognized as removed?  I imagine that gets somewhat technical.

(In reply to :Gijs (he/him) from comment #54)
> This pref is a bit of a strange case because it was never exposed, so anyone
> running into this would be checking about:config, rather than the
> preferences/options. Normally, this type of removal affects prefs that had
> UI, in which case the UI is gone and it's clear that something was removed
> (even if we left the internal pref state and you could find it in
> about:config if you went looking).

It was a long time ago, but it used to be exposed in options.  Just to be sure I was recalling that correctly, I dig up an article about it being there until at least Firefox 4 or 7 years and quite a few releases ago!  I thought it was more recent (I remember a point where there were a handful of customization options that were relegated to about:config), but I could be remembering wrong because of how the versioning changed around this time.

https://webtrickz.com/how-to-enable-save-and-quit-option-in-firefox-4/

(In reply to Pascal Chevrel:pascalc from comment #55)
> (In reply to :Gijs (he/him) from comment #54)
> > Pascal: can you update the relnote to include something as suggested by
> > LepidopTERA? Maybe "You can restore your session by ...", rather than "Users
> > are encouraged to..." to make it less impersonal.
> 
> Updated

Looks great!  Thank you, Pascal!

Comment 58

[:Gijs (he/him)]

(In reply to LepidopTERA from comment #57)
> Gijs, without going too far off the original topic of this bug, you're
> saying all removed preferences end up in prefs.js?

No. Values for all *modified* preferences are stored in prefs.js . So you went to about:config (or used UI in Fx3 or whatever) and set the pref. That gets it stored into prefs.js . It will never be removed from prefs.js unless we write Firefox code that specifically unsets such a (user-set) pref.

about:config lists the combination (disjunction) of all the prefs from prefs.js, and all the preferences for which Firefox knows a default value.

>  Even though it's still
> in about:config, how is it recognized as removed?

It's not "recognized" as removed - there is just no code that reads the preference. The preference store is just a giant mapping from preference names to values (like, I dunno, variables in math equations, if that makes more sense than the computer science meaning of a "dictionary" or "map" - you have a label for it, like "x", and it has a value, like 42 or `true` or even a bit of text, like in the case of your default homepage which stores a URL).

That store itself doesn't "do anything" - the only thing that does something is code that reads prefs out of the mapping/dictionary. Like, you can go to about:config, right click, create a new pref with the name "firefox.shoulddowhatiwant", and set it to `true`, but it won't actually make anything happen (sadly!). But it'll be stored in prefs.js . You can remove it again by using 'reset' as I suggested in comment #54. That'll remove the item from prefs.js, and Firefox will fall back to any default value for that pref that it might know about (which it doesn't, in this case).

Effectively, `browser.showQuitWarning` is now just as (non)effective as `firefox.shoulddowhatiwant`, because the code that used to check `browser.showQuitWarning` was removed.

Comment 61

[freeseek]

This is a BUG. Why isn't Mozilla fixing this? There are tons of people out there pressing Ctrl+Q instead of Ctrl+W by mistake and closing all the windows when that was not the intended behaviour. Google Chrome uses Ctrl+Shift+W rather than Ctrl+Q. That makes so much more sense. Microsoft used Ctrl+Alt+Delete to switch off the system, exactly because that would be a difficult combination of keys to press together by mistake. You cannot say the same about Ctrl+Q. Who is the manager at Mozilla that is unable to understand such a simple concept? Whoever is reading this at Mozilla: tell your managers to stop being stubborn and to do the right thing. The managers for Google Chrome already know it is important to listen: https://www.ghacks.net/2018/10/22/google-retires-ctrl-shift-q-in-chrome-to-exit-web-browser/

Comment 62

[Sören Hentzschel]

>(In reply to freeseek from comment #61)
> This is a BUG. Why isn't Mozilla fixing this?

It's already fixed. That's the reason why the status of this ticket is "RESOLVED FIXED in Firefox 63" - Firefox 63 is the current version of Firefox. Maybe you should test BEFORE you write angry comments…

Comment 63

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Reminder that this is a bug tracker, not Reddit. Discussions pertinent to resolving the bug belong here. Other discussions need to go to Discourse or the dev-firefox mailing list. All our discussions are governed by our Participation Guidelines and we remove comments that violate them. (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html)

I'm closing comments on this bug to non-Editbugs users.