1257407 - AudioContext statechange event not received when MSG is already running

Status: RESOLVED DUPLICATE of bug 1259831

(Core :: Web Audio, defect, P2)

Description

[Karl Tomlinson (:karlt)]

Attachment: statechange-1.html

STR:
1) Load testcase in new browser.
   Expect: "statechange running".
   Actual: "statechange running".
2) Reload.
   Expect: "statechange running".
   Actual: nothing.

"A newly-created AudioContext will always begin in the suspended state, and a state change event will be fired whenever the state changes to a different state."
http://webaudio.github.io/web-audio-api/#widl-BaseAudioContext-onstatechange

Comment 1

[Karl Tomlinson (:karlt)]

By reverting c9a6d9c23418 and 8904253408ca, old revisions can be rebuilt to
identify the trigger of the regression as

https://hg.mozilla.org/mozilla-central/rev/2624ea64e7ab

Comment 2

[Maire Reavy [:mreavy]]

Karl -- Are you planning to take this (since the test for Bug 1255618 depends on this)?  Or should I find someone else?  This is a carryover regression and impacting our ability to write tests; so I need to find an owner.  Thanks!

Comment 3

[Karl Tomlinson (:karlt)]

I wasn't planning to take this, not right now at least.

This is a more recent feature (Bug 1094764), which I suspect still has some
details to sort out (bug 1209598), and I'm not expecting wide use yet.  It
would be nice to fix just for the sake of the test for bug 1255618, but I see at as
considerably less important than some of the other bugs.

I'm not familiar with how this worked before or why it doesn't now, so I'm not
sure how difficult it is to fix.  It may be something simple to correct, but
there is a chance it is related to other start/stop issues like bug 1209598
and bug 1228226.

Comment 4

[Maire Reavy [:mreavy]]

Thanks, Karl.  

Liz -- Karl did a good job of explaining why this isn't worth being tracked by relman in Comment 3.  (It's a more recent feature that doesn't see wide use yet, and we have more important issues to address.)  I'd like to get this untracked by releasehealth/relman.  Thanks.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Relman isn't tracking this -- I'll make that clear and then take a look at the Platform triage query to see if we can remove stuff that has tracking-firefox46 and 47 set to minus. 

Or, we could use some other way to tag minor regressions. Emma is this something you cover in your triage plan?  I don't check for every recent regression -- I tend to only see them if QE or developers or triagers nominate them for tracking.

Comment 6

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

I think this is part of getting some consistent rules on how we mark things as regressions, and we need to push back on how we're defining things as regressions.

Comment 7

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

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #5)
> Or, we could use some other way to tag minor regressions. Emma is this
> something you cover in your triage plan?  I don't check for every recent
> regression -- I tend to only see them if QE or developers or triagers
> nominate them for tracking.

In the triage plan, if there's uncertainty as to a bugs severity, it's best to needinfo someone to research. The bug remains untriaged, and the component owner won't be pestered about it unless hte needinfo's not cleared in a week or less.

Comment 8

[Karl Tomlinson (:karlt)]

This was fixed between 8c3fd523d75bd30f691ca2d6cfdad18d576392a1 and 2b7c421063ad7e30b6491d62ed8480ca333b628a.
Suspect bug 1259831.