This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 19902 - Clarify what happens if you set PannerNode.{panningModel,distanceModel} to an invalid value
Summary: Clarify what happens if you set PannerNode.{panningModel,distanceModel} to an...
Status: CLOSED WONTFIX
Alias: None
Product: AudioWG
Classification: Unclassified
Component: Web Audio API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: TBD
Assignee: Chris Rogers
QA Contact: public-audio
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-07 23:28 UTC by Ehsan Akhgari [:ehsan]
Modified: 2014-10-28 17:17 UTC (History)
0 users

See Also:


Attachments

Description Ehsan Akhgari [:ehsan] 2012-11-07 23:28:43 UTC
I think we should throw DOM_INDEX_SIZE_ERR.

(This and other similar bugs wouldn't have been a problem if we used Web IDL enums... :/ )
Comment 1 Chris Rogers 2012-11-13 22:32:30 UTC
If you feel strongly about Web IDL enums, we can still consider switching to them.  But since these enums are already in wide use as integers, we'd have to support setters as either int or string.

We'd still have to throw an exception for illegal values even for Web IDL.
Comment 2 Ehsan Akhgari [:ehsan] 2012-11-15 01:32:24 UTC
We're considering enabling Web IDL enum attribute setters to throw if passed an invalid value, which would mean that we'll get what I'm asking for here for free.  And yes, I still think that using Web IDL enums would be a good change because of the increase in code readability and the possibilities of using the IDL parser to do various sorts of checking for the implementers.

However I don't think that it would be very good for us to allow setting these both as integers and strings...  How did WebKit deal with the other breaking changes that was recently made in the spec (such as renaming functions, etc.)?
Comment 3 Chris Rogers 2012-11-16 18:41:46 UTC
(In reply to comment #2)
> We're considering enabling Web IDL enum attribute setters to throw if passed
> an invalid value, which would mean that we'll get what I'm asking for here
> for free.  And yes, I still think that using Web IDL enums would be a good
> change because of the increase in code readability and the possibilities of
> using the IDL parser to do various sorts of checking for the implementers.
> 
> However I don't think that it would be very good for us to allow setting
> these both as integers and strings...  How did WebKit deal with the other
> breaking changes that was recently made in the spec (such as renaming
> functions, etc.)?

For the recent name changes such as noteOn() -> start(), WebKit continues to provide legacy support, which can eventually be phased out during a transition period.  I added a section in the spec called "Deprecation Notes" to make note of these types of changes.  Different implementations may choose to support or not support the legacy names, and for how long they would be supported.
Comment 4 Ehsan Akhgari [:ehsan] 2012-11-16 19:31:34 UTC
OK.  Can the same approach be taken about the numeric attributes?
Comment 5 Chris Rogers 2012-11-16 19:58:19 UTC
(In reply to comment #4)
> OK.  Can the same approach be taken about the numeric attributes?

Yes, for the "enum" type attributes I think so.  The only gotcha is that the "getters" would now return a string instead of an integer.  But I think the main backwards compatibility concern is people setting these attributes, so I'm not so worried about that.
Comment 6 Ehsan Akhgari [:ehsan] 2012-11-16 22:18:58 UTC
Yep, I think that makes sense.  Thanks!
Comment 7 Olivier Thereaux 2014-10-28 17:14:30 UTC
Web Audio API issues have been migrated to Github. 
See https://github.com/WebAudio/web-audio-api/issues
Comment 8 Olivier Thereaux 2014-10-28 17:17:27 UTC
Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.