1256280 - (e10s-specific) User can no longer rely on background tabs that are shown as not crashed (consider processCount > 1)

Status: NEW

(Firefox :: General, defect)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 48, 32bit, ID 20160312030405
STR:
1. Open attached "testcase 1" in a new pinned tab
2.A) Click "Toggle Favicon" to test cases without favicons (when some chat doesn't show/have favicon
     OR there were troubles with internet connection OR user disabled images via about:config)
2.B) Do nothing (testing with favicons - this will be available after bug 1227630)
3. Click "Start Testing"
4. Within 5 seconds open new tab, then crash content process (plugin-container.exe) somehow.
5. Wait 15 seconds

AR:
 (A) The pinned tab from Step 1 doesn't change favicon and doesn't show highlight
 (B) The pinned tab from Step 1 doesn't show highlight (caused by [titlechanged] attribute in tab)

ER:
 There should be a way to distinguish crashed background tabs from not crashed.
 In more detail: if an active tab crashed, user no longer knows which background tabs have crashed
 and which haven't. So he has to remember all active tabs from current session, and check them all.

Use case:
 I was waiting an important email without knowing that the tab with Yandex mail has crashed.
 So I only switched to email tab only ~30minutes after the mail was delivered, because I was sure
 that once a new email is delivered, the favicon will change, and browser will highlight the tab.

Note:
 I subscribed to bug 1227630 (broken by "enhancement" in bug 1209689), but it's not going anywhere

Comment 2

[Jim Mathies [:jimm]]

> There should be a way to distinguish crashed background tabs from not crashed.

Bug 1209689 caused this by eliminating this distinction. I don't think we want go back on this since the user experience is worse.

We might want to consider auto-reloading of pinned tabs once a user action restarts the content process.

mulit-process tabs will help address this as well.

Comment 3

[arni2033]

(In reply to Jim Mathies [:jimm] from comment #2)
> since the user experience is worse
At which point??? User experience is worse now, after bug 1209689.
In bug 1209689, some people didn't think well about UX actually. They said exactly "browser shows that it's more broken than it is". That's not true. The browser is exactly that broken.

When user's progress in background tab is ruined, you don't even want to notify the user
If I use some site that doesn't restore text in entry field, your suggested change will silently reload the tab and scroll it to the same position. So it will look like the site deleted that input by itself. Or else user can spend some times testing/debugging that site trying to find the culprit.
If user's data was ruined/lost, please notify him that it happened because of crashed tab, not because of a buggy site.

Correction:
In "Use case" I wasn't actually expecting favicon to change, because I disabled images via pref
permissions.default.image in about:config. But everything described above stays valid, since there's a plan to actually fix bug 1227630, and given the fact that some sites don't use favicons.

Comment 4

[Danial Horton]

And this is why i am still on Firefox 44

Comment 5

[Jim Mathies [:jimm]]

(In reply to arni2033 from comment #3)
> (In reply to Jim Mathies [:jimm] from comment #2)
> > since the user experience is worse
> At which point??? User experience is worse now, after bug 1209689.
> In bug 1209689, some people didn't think well about UX actually. They said
> exactly "browser shows that it's more broken than it is". That's not true.
> The browser is exactly that broken.

Tabs are unloaded, not broken. This is the same default behavior we use for session restore. 

> When user's progress in background tab is ruined, you don't even want to
> notify the user.

It shouldn't be ruined, the tab is just unloaded. When it reloads state should restore unless the underlying site prevents it.

> If I use some site that doesn't restore text in entry field, your suggested
> change will silently reload the tab and scroll it to the same position.

Bug 1209689 just changed the visible indicators associated with crashed tabs. The way we handle data in a tab that crashes and gets restored hasn't changed.

> So
> it will look like the site deleted that input by itself. Or else user can
> spend some times testing/debugging that site trying to find the culprit.
> If user's data was ruined/lost, please notify him that it happened because
> of crashed tab, not because of a buggy site.

I don't understand what your point is here, can you clarify?

Comment 6

[Jim Mathies [:jimm]]

(In reply to Danial Horton from comment #4)
> And this is why i am still on Firefox 44

Why is this?

Comment 7

[Danial Horton]

The talos regression in 45+ for session restoring is unacceptable.

Comment 8

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Jim Mathies [:jimm] from comment #2)
> > There should be a way to distinguish crashed background tabs from not crashed.
> 
> Bug 1209689 caused this by eliminating this distinction. I don't think we
> want go back on this since the user experience is worse.
> 
> We might want to consider auto-reloading of pinned tabs once a user action
> restarts the content process.
> 
> mulit-process tabs will help address this as well.

I agree, I don't think it's worth fixing this for the single-process use case and then again later for multi. It's an annoying bug and a lot of sites spam the favicon to notify the user so I think it's a P1 in multi.

Comment 9

[arni2033]

(In reply to Jim Mathies [:jimm] from comment #5)
> Tabs are unloaded, not broken. This is the same default behavior we use for session restore. 
When a tab is unloaded/reloaded without user's knowledge - that's a breakage.
(Except when site reloads tab. It is either desired behavior of site, or a bug in the site itself.
 Anyway, it's obviously on the site's side.)

> It shouldn't be ruined, the tab is just unloaded. When it reloads state
> should restore unless the underlying site prevents it.
I really hope that you aren't _pretending_ that you're unaware of all the cases
when the data may be lost...   v_v

Here're some cases I can list immediately:
1) Site is set to always ask password when user loads it.
2) Site provides some default page when you first enter it, ever.
3) Site is using "Save" button for some fancy stuff, and user decided to press it later
4) Site is using some application, e.g. browser game, which never restore their state on reload.
   But the favicon will stay the same. So I will never know if my village was attacked.
5) Site does something more complex than static html, so form data isn't stored. This happens even
   on Bugzilla: (1) Click "tag" (2) type "spam" (3) reload page
6) Site uses [contenteditable] that isn't stored by Firefox. Type smth on this page, then reload it:
> data:text/html,<div contenteditable style="background:gray"><br>

So after the "reload trick" sites won't load at the same state. Where did this assumption even came from? It almost never works like that. There are some infinite scrolling pages etc.
If you reload/unload tab, the user must be notified.
OR it appears that you mess with opened tabs for unclear reason. That's malicious behavior.

> Bug 1209689 just changed the visible indicators associated with crashed tabs.
> The way we handle data in a tab that crashes and gets restored hasn't changed.
So I haven't reported anything about data restoring! Huh. Read comment 0.
It doesn't say "my data is not restored properly", but it says "I'm not notified _WHY_ my data haven't restored properly. The fact that data is never restored properly is explained above.

> > it will look like the site deleted that input by itself. Or else user can spend some times
> > testing/debugging that site trying to find the culprit. If user's data was ruined/lost, please
> > notify him that it happened because of crashed tab, not because of a buggy site.
> 
> I don't understand what your point is here, can you clarify?
First you make some changes to the page
Then, you leave the page
Then (one of?) content process(es) crashes
Finally, you go back to the same page and find your changes cancelled for unclear reason.
^
The first thing that comes to mind is that the data was deleted by the site.
Well, I haven't expected firefox to interfere in my work before bug 1209689.

Comment 10

[Jim Mathies [:jimm]]

(In reply to arni2033 from comment #9)
> (In reply to Jim Mathies [:jimm] from comment #5)
> > Tabs are unloaded, not broken. This is the same default behavior we use for session restore. 
> When a tab is unloaded/reloaded without user's knowledge - that's a breakage.
> (Except when site reloads tab. It is either desired behavior of site, or a
> bug in the site itself.
>  Anyway, it's obviously on the site's side.)
> 
> > It shouldn't be ruined, the tab is just unloaded. When it reloads state
> > should restore unless the underlying site prevents it.
> I really hope that you aren't _pretending_ that you're unaware of all the
> cases
> when the data may be lost...   v_v
> 
> Here're some cases I can list immediately:
> 1) Site is set to always ask password when user loads it.
> 2) Site provides some default page when you first enter it, ever.
> 3) Site is using "Save" button for some fancy stuff, and user decided to
> press it later
> 4) Site is using some application, e.g. browser game, which never restore
> their state on reload.
>    But the favicon will stay the same. So I will never know if my village
> was attacked.
> 5) Site does something more complex than static html, so form data isn't
> stored. This happens even
>    on Bugzilla: (1) Click "tag" (2) type "spam" (3) reload page
> 6) Site uses [contenteditable] that isn't stored by Firefox. Type smth on
> this page, then reload it:
> > data:text/html,<div contenteditable style="background:gray"><br>
> 
> So after the "reload trick" sites won't load at the same state. Where did
> this assumption even came from? It almost never works like that. There are
> some infinite scrolling pages etc.

Agreed. The breakage you describe here though is the same that occurs in single process firefox with a browser crash so e10s didn't make this situation worse. In fact it made it slightly better in that the browser never shuts down, saving the user effort.

> > Bug 1209689 just changed the visible indicators associated with crashed tabs.
> > The way we handle data in a tab that crashes and gets restored hasn't changed.
> So I haven't reported anything about data restoring! Huh. Read comment 0.
> It doesn't say "my data is not restored properly", but it says "I'm not
> notified _WHY_ my data haven't restored properly. The fact that data is
> never restored properly is explained above.
> 
> > > it will look like the site deleted that input by itself. Or else user can spend some times
> > > testing/debugging that site trying to find the culprit. If user's data was ruined/lost, please
> > > notify him that it happened because of crashed tab, not because of a buggy site.
> > 
> > I don't understand what your point is here, can you clarify?
> First you make some changes to the page
> Then, you leave the page
> Then (one of?) content process(es) crashes
> Finally, you go back to the same page and find your changes cancelled for
> unclear reason.
> ^
> The first thing that comes to mind is that the data was deleted by the site.
> Well, I haven't expected firefox to interfere in my work before bug 1209689.

Ok, but you knew that tabs crashed right? We display the tab crashed page in the foreground tab. Making a connection between seeing the tab crashed page and lost data in a background might not be obvious, but this is the kind of thing users generally get used to over time.

Pinned tabs may be something we want to take more seriously due to lost tab notifications. We should look at other browsers to see how they handle this. I'll file a follow up on this.

Comment 11

[arni2033]

(In reply to Jim Mathies [:jimm] from comment #10)
> The breakage you describe here though is the same that occurs in single process firefox
> with a browser crash so e10s didn't make this situation worse
That is clearly not true. In non-e10s firefox says "Sorry, I touched your tabs and ruined your work,
but only because there was a crash". In e10s mode it looks like it just does what it wants, because
it doesn't provide a reason. The situation is especially unclear if user installed "Unload tab"
extension or set processCount to >= 2. Still, this malicious behavior is only presented in e10s mode

> it made it slightly better in that the browser never shuts down, saving the user effort
That is clearly not true. You yourself said earlier that it's not true, because you do the same thing as in non-e10s mode: "This is the same behavior we use for session restore" (comment 5)
So you are saving (the same small part) of user's effort in each case. This but is NOT about how much of user's progress browser actually saves.

> Ok, but you knew that tabs crashed right?
I know that _some_ tabs were crashed, but I don't know which tabs exactly were crashed
(i.e. processCount > 1)
So, EVEN if I remember all tabs I visited during current session, I will still have to check each of them to find out which ones were crashed. (that was mentioned in comment 0   ಠ_ಠ)

> Pinned tabs may be something we want to take more seriously due to lost tab notifications
Did you ever considered sound notifications? Vkontakte (https://vk.com/) uses them, and I almost always have several normal (not pinned) tabs opened.

Comment 12

[Jim Mathies [:jimm]]

(In reply to arni2033 from comment #11)
> (In reply to Jim Mathies [:jimm] from comment #10)
> > The breakage you describe here though is the same that occurs in single process firefox
> > with a browser crash so e10s didn't make this situation worse
> That is clearly not true. In non-e10s firefox says "Sorry, I touched your
> tabs and ruined your work,
> but only because there was a crash". In e10s mode it looks like it just does
> what it wants, because
> it doesn't provide a reason.

We display the crashed tab page in the foreground tab so we do provide notification that something has gone wrong. The only thing that was removed here was a tab icon indicating which tabs were affected. Users should should be able to pick up that all tabs were affected.

> The situation is especially unclear if user
> installed "Unload tab"
> extension or set processCount to >= 2. Still, this malicious behavior is
> only presented in e10s mode

Whatever we do here is part of the follow up process-per-tab project which is tracked by bug 'e10s-multi'.

> 
> > it made it slightly better in that the browser never shuts down, saving the user effort
> That is clearly not true. You yourself said earlier that it's not true,
> because you do the same thing as in non-e10s mode: "This is the same
> behavior we use for session restore" (comment 5)
> So you are saving (the same small part) of user's effort in each case. This
> but is NOT about how much of user's progress browser actually saves.

In a straight comparison between a crashed browser and crashed tabs, imo crashed tabs are a better user experience.

> > Ok, but you knew that tabs crashed right?
> I know that _some_ tabs were crashed, but I don't know which tabs exactly
> were crashed
> (i.e. processCount > 1)

See above, this is out of scope for the current e10s project. I see what you're saying though, the user doesn't know which tab is affected by a crash. I wonder how Chrome and edge deal with this.

> > Pinned tabs may be something we want to take more seriously due to lost tab notifications
> Did you ever considered sound notifications? Vkontakte (https://vk.com/)
> uses them, and I almost always have several normal (not pinned) tabs opened.

We have to make decisions that balance performance and usability. If tabs crash, what would you prefer we do? If one tab is has a site loaded that requires the user to login before it can notify with prompts or sound, how do you feel Firefox should deal with it?

Comment 13

[arni2033]

(In reply to Jim Mathies [:jimm] from comment #12)
> I see what you're saying
Oh, now I finally see what _you_ are saying... None of my comments were related to processCount==1

> We display the crashed tab page in the foreground tab
That's not true. See the penultimate paragraph, in parentheses.

> The only thing that was removed here was a tab icon indicating which tabs were affected.
> Users should should be able to pick up that all tabs were affected.
That's not true for processCount > 1
First of all, your words are equal to:
«When some tabs crash, browser says "all your tabs have crashed". Except doesn't show crash badges»
In the past, e10s-browser showed all crashed tabs (not all) correctly, now it says that all tabs
have crashed. It makes user _feel_ that browser it more broken that it is, instead of _seeing_ how
exactly is broken. That is what has been implemented in bug 1209689. And despite the fact that it
that bug was supposed to make browser "less broken" (sic!)

> Whatever we do here is part of the follow up process-per-tab project
Well, I'm ok with waiting several years until you fix/back out the offending part of bug 1209689. But I have serious doubts on any possible way of resolution/hacking except the partial backout of
bug 1209689. I'm here only to see for each breakage, some elder developer say that that breakage
is desired pain for FX users or that it will eventually be fixed.
And to explain how hacks/workarounds could lead to the same issues.

> In a straight comparison between a crashed browser and crashed tabs, imo crashed tabs
> are a better user experience.
There're always different aspects of a feature to discuss. I meant that currently non-e10s mode
doesn't touch my tabs by itself [good], and e10s mode does [bad].

OK, if it's unclear (it is), then try to compare e10s (>1 processes) behavior before and after
1209689, especially the time required to determine which tabs were actually crashed.
I suppose the suggested workflow for user here is:
1) get a notification about crashed tabs
2) find which tabs could be crashed
3) check important tabs from (2) and decide what to do w/ them
Now user spends ~N*T*K time to (3) instead of ~T*K time (where N - is number of content processes,
T - is time required to check 1 tab, K - is approximate number of tabs in each process)
This is regression. In the past user used to spend T*K time to (3)

> I wonder how Chrome and edge deal with this.
Chrome does exactly what Firefox did before it was regressed by bug 1209689. Screencast:
 https://dl.dropboxusercontent.com/s/7e46zomt20c332a/bug%201256280%20comment%2013.webm?dl=0
I don't know how browsers with scrollable tabs list handle this, because there're always invisible crashed tabs. Only showing a crashed icon is enough for Chrome and probably not enough them...

> We have to make decisions that balance performance and usability. If tabs crash, what
> would you prefer we do? If one tab is has a site loaded that requires the user to login
> before it can notify with prompts or sound, how do you feel Firefox should deal with it?
I sure don't see any performance or usability improved in 1209689...
Just don't try to "fix" the tab, like you didn't in the old times. It's almost always impossible,
and reloading tabs only brings more confusion. The optimal way is to say:
"Some tabs were crashed. Go check them", and let the user to quickly check them and do whatever he
wants. Possibly I won't want to restore some tabs, because I may think that they caused the crash.

Browser should always explain why it did some actions with the tab. That's "ux-control" or something like that. You should know better.
When it comes to background tabs that can provide visual/sound notifications, then:
(If you think that 1 dialog is enough to make it clear for user that _many_ tabs were crashed...
 Then again, what happens if it will appear in background window??? Again, breakage 1209689)
Browser should at least provide an explanation why there were no messages from that tab, when user
finally finds it. I.e. show a dialog saying that the tab was crashed. That's how other browsers do it

And, actually, If I switch to the tab before the first visible tab in tabs list, I, as a
user, never know the reason why it reloads (if it was crashed). I can only make assumptions.
So even this aspect of bug 1209689 is bad.
I hope it will be just backed out since multi-multi-process was hardly considered in that bug.

Comment 14

[Jim Mathies [:jimm]]

> > I wonder how Chrome and edge deal with this.
> Chrome does exactly what Firefox did before it was regressed by bug 1209689. Screencast:
>  https://dl.dropboxusercontent.com/s/7e46zomt20c332a/bug%201256280%20comment%2013.webm?dl=0
> I don't know how browsers with scrollable tabs list handle this, because there're always
> invisible crashed tabs. Only showing a crashed icon is enough for Chrome and
> probably not enough them...

This is interesting. I'd bet there are other tabs in your tab list here that crashed that didn't show anything. Unless you really had 17 tab processes running when you shot this screencast.

Comment 15

[arni2033]

(In reply to Jim Mathies [:jimm] from comment #14)
> This is interesting. I'd bet there are other tabs in your tab list here that crashed that didn't
> show anything. Unless you really had 17 tab processes running when you shot this screencast.
There were 5 processes for ~5 loaded tabs. It's hard (for me) to get GoogleChrome storing 2 tabs in 1
proc. When I load all 17 tabs, I get 20 processes. But I'm fairly sure that it marks all crashed tabs
as crashed and puts special dialog in each tab to explain what happened. If I crash all processes one
by one, I get all 17 tabs with "crashed" icon and explanatory dialogs. Well that's a ux-control!

Comment 17

[Gabor Krizsanits (INACTIVE)]

I do think that we have to sort out our crash reporting story, mainly because we can miss out notifications from crashed background tabs. Also, once we have proper service workers, we have to figure out a recovery story there too. Let's discuss this on the next e10s-multi meeting.