Closed Bug 1188548 Opened 5 years ago Closed 5 years ago

Give overlay-icon a status attribute instead of boolean attributes

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ehsan, Assigned: ehsan)

References

Details

Attachments

(1 file, 1 obsolete file)

See bug 486262 comment 154.
Attached patch WIP for bug 1188548 (obsolete) — Splinter Review
Attachment #8640862 - Attachment is obsolete: true
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?
Assignee: nobody → ehsan
Flags: needinfo?(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.
Flags: needinfo?(dao)
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?
Flags: needinfo?(shorlander)
(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.
(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.
Flags: needinfo?(shorlander)
(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.
Flags: needinfo?(shorlander)
See Also: → 1191038
(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.
Flags: needinfo?(shorlander)
(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.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.