Closed Bug 1257407 Opened 9 years ago Closed 8 years ago

AudioContext statechange event not received when MSG is already running

Categories

(Core :: Web Audio, defect, P2)

43 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1259831
Tracking Status
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 - wontfix
firefox48 --- wontfix

People

(Reporter: karlt, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

Attached file statechange-1.html (deleted) —
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
Blocks: 1255618
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
Blocks: 1189506
Keywords: regression
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!
Flags: needinfo?(karlt)
Rank: 10
Priority: -- → P1
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.
Flags: needinfo?(karlt)
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.
Rank: 10 → 29
Flags: needinfo?(lhenry)
Priority: P1 → P2
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.
Flags: needinfo?(lhenry) → needinfo?(ehumphries)
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.
(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.
Flags: needinfo?(ehumphries)
Version: Trunk → 43 Branch
This was fixed between 8c3fd523d75bd30f691ca2d6cfdad18d576392a1 and 2b7c421063ad7e30b6491d62ed8480ca333b628a. Suspect bug 1259831.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: