1188548 - Give overlay-icon a status attribute instead of boolean attributes

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[(no longer active)]

See bug 486262 comment 154.

Comment 1

[(no longer active)]

Attachment: WIP for bug 1188548

Comment 2

[(no longer active)]

Attachment: WIP for bug 1188548

Comment 3

[(no longer active)]

I gave this a shot, but then quickly realized that this will result in mode errors, such as the below:

1. The tab starts to play audio.
2. The user mutes it.
3. The tab crashes.
4. The user reloads the tab.
5. The reloading code (see around "If the browser is loading" in the patch) sets the status attribute to "" because it cannot remember that it was "muted" before.

Therefore the UI shows the tab as unmuted, while it will be muted.

I think we should WONTFIX this bug.  All of these three attributes can be set in arbitrary combinations.

What do you think, Dao?

Comment 4

[Dão Gottwald [:dao]]

In my book a crashed tab should be neither "playing sound" nor "muted", since the audio died along with the rest of the page. That the playing/muted icon currently persist in that case feels like a bug to me.

Comment 5

[(no longer active)]

The question is not about whether a crashed tab can be muted or playing, it is about whether the tab should be muted or not after it is restored from a crashed state.

Stephen, this is ultimately a UX issue.  What do you think?

Comment 6

[Dão Gottwald [:dao]]

(In reply to :Ehsan Akhgari (not reviewing patches, not reading bugmail, needinfo? me!) from comment #5)
> The question is not about whether a crashed tab can be muted or playing, it
> is about whether the tab should be muted or not after it is restored from a
> crashed state.

These questions are connected, since we don't seem to actually restore the muted state, but it persists throughout the whole process. Which means that the crashed tab gets bogus indicators.

Comment 7

[Stephen Horlander [:shorlander]]

(In reply to Dão Gottwald [:dao] from comment #4)
> In my book a crashed tab should be neither "playing sound" nor "muted",
> since the audio died along with the rest of the page. That the playing/muted
> icon currently persist in that case feels like a bug to me.

Maybe I am not understanding correctly but these states seem mutually exclusive to me too.

- A crashed tab can't be playing Audio so shouldn't have a tab audio indicator.
- If you "reboot" the tab it can then have a tab audio indicator, but that indicator should reflect the actual muted vs. non-muted state.

Comment 8

[(no longer active)]

(In reply to Stephen Horlander [:shorlander] from comment #7)
> (In reply to Dão Gottwald [:dao] from comment #4)
> > In my book a crashed tab should be neither "playing sound" nor "muted",
> > since the audio died along with the rest of the page. That the playing/muted
> > icon currently persist in that case feels like a bug to me.
> 
> Maybe I am not understanding correctly but these states seem mutually
> exclusive to me too.
> 
> - A crashed tab can't be playing Audio so shouldn't have a tab audio
> indicator.

Yes, I think this part is completely non-controversial!  Filed as bug 1191038.

> - If you "reboot" the tab it can then have a tab audio indicator, but that
> indicator should reflect the actual muted vs. non-muted state.

Agreed.  But the question here is, should the tab be muted or not after this sequence:

1. The user goes to youtube, sets it to be muted.
2. The user navigates to soundcloud on the same tab.  The tab remains muted.
2. The tab crashes.
3. The user restores the tab by reloading it.  Should the tab be muted now?

We maintain the muted flag across navigations (step 2), but what is not clear is whether we should remember that the tab should be muted after we restore it from a crashed state.

Comment 9

[Stephen Horlander [:shorlander]]

(In reply to Ehsan Akhgari (not reviewing patches, not reading bugmail, needinfo? me!) from comment #8)
> We maintain the muted flag across navigations (step 2), but what is not
> clear is whether we should remember that the tab should be muted after we
> restore it from a crashed state.

I think we should. The crash is unfortunate and not user initiated (obviously :)) We shouldn't reset the tab state because Firefox messed up.

Comment 10

[(no longer active)]

(In reply to Stephen Horlander [:shorlander] from comment #9)
> (In reply to Ehsan Akhgari (not reviewing patches, not reading bugmail,
> needinfo? me!) from comment #8)
> > We maintain the muted flag across navigations (step 2), but what is not
> > clear is whether we should remember that the tab should be muted after we
> > restore it from a crashed state.
> 
> I think we should. The crash is unfortunate and not user initiated
> (obviously :)) We shouldn't reset the tab state because Firefox messed up.

OK, thanks.  Based on this, we should WONTFIX this bug.

I filed bug 1191081 for setting the correct muted state after resuming from a crash.