Bug 14843 - Range interface uses enum, which doesn't exist in WebIDL
Range interface uses enum, which doesn't exist in WebIDL
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: DOM
unspecified
All All
: P2 normal
: ---
Assigned To: Anne
public-webapps-bugzilla
http://dvcs.w3.org/hg/domcore/raw-fil...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-16 18:01 UTC by Aryeh Gregor
Modified: 2011-12-10 11:27 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aryeh Gregor 2011-11-16 18:01:06 UTC
enum CompareHow : unsigned short {
    START_TO_START = 0,
    START_TO_END   = 1,
    END_TO_END     = 2,
    END_TO_START   = 3
  };

This doesn't appear to mean anything in current WebIDL, unless I'm missing something as usual.
Comment 1 Ms2ger 2011-11-16 18:13:24 UTC
Not missing anything, I just haven't got around to asking heycam to spec it. The idea is that WebIDL throws when passing an invalid value to compareBoundaryPoints, rather than having the check in prose.
Comment 2 Anne 2011-11-16 18:28:17 UTC
We might want to just do this one ourselves. Going forward I think we only want to have and allow string enums.
Comment 3 Aryeh Gregor 2011-11-16 21:01:46 UTC
This is causing the new WebIDL test framework to fail to parse the Range interface declaration, so I had to comment it out:

http://w3c-test.org/webapps/DOMCore/tests/submissions/AryehGregor/interfaces.html

We'd want to update WebIDL before we could ask the maintainer of the library we're using to update that.  I could comment out just this chunk of the IDL if necessary, of course, but it would be nicer if we could parse it as-is.
Comment 4 Robin Berjon 2011-11-17 10:36:55 UTC
(In reply to comment #3)
> We'd want to update WebIDL before we could ask the maintainer of the library
> we're using to update that.  I could comment out just this chunk of the IDL if
> necessary, of course, but it would be nicer if we could parse it as-is.

I'm the author of the library. Since I have only been needing it intermittently in recent months, my plan has been to wait for WebIDL to actually stabilise before doing a complete update. That being said, several people have needed changes to match WebIDL's fluctuations and simply patched it directly (cf https://github.com/darobin/webidl.js).

If you're really stuck and need this update though, email me and I'll try to fit it in.
Comment 5 Aryeh Gregor 2011-11-18 00:04:31 UTC
Thanks!  There's no change to make here, because WebIDL isn't updated yet.  DOM4's behavior here is currently just not defined.  As I try parsing more specs' IDL blocks, I'll figure out what missing features are actually causing problems, although for the time being I'll just comment out the problematic bits.

As far as this bug goes, though: DOM4 as it stands just doesn't define what compareBoundaryPoints is supposed to do.  If we're going to update WebIDL, or even add the definition to DOM4, okay -- but unless someone is planning to do that really soon, we should throw the exception from prose for now so that it's actually a precise and testable requirement.
Comment 6 Dominique Hazael-Massieux 2011-11-24 15:56:29 UTC
I think this is a duplicate of http://www.w3.org/Bugs/Public/show_bug.cgi?id=11451 (with the possible exception that that Bug refers to "string" enum only)

*** This bug has been marked as a duplicate of bug 11451 ***
Comment 7 Aryeh Gregor 2011-12-01 18:50:57 UTC
Not a duplicate.  Fixing that bug would make this one moot, but if that isn't fixed, this should be fixed separately (by removing the enum from the spec).
Comment 8 Cameron McCormack 2011-12-09 06:02:25 UTC
Given we're all agreed we shouldn't be introducing new integer enumerations, let's do it manually with constants as Anne suggests in comment 2, and just leave it to bug 11451 for string enums.

Flicking back to DOM Core to remove the enum from the IDL.
Comment 9 Cameron McCormack 2011-12-09 06:16:29 UTC
See also bug 12810, which I'm about to WONTFIX.