721569 - Blob should have a constructor.

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The latest version of the File API spec you can now construct a Blob directly, without having to use a BlobBuilder.

So the following should work:

b1 = new Blob([blob1, blob2, arraybuffer]);
b2 = new Blob([b1, "foo"], { type: "image/png" });

Masatoshi-san, would you be interested in taking this? We have decent support for both constructors and dictionaries these days, so it shouldn't be too much work.

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

    2.93 +      if (element.isObject()) {
    2.94 +        JSObject* obj = &element.toObject();
    2.95 +        if (!obj) {
    2.96 +          return NS_ERROR_DOM_INVALID_STATE_ERR; // null
    2.97 +        }

That's just wrong. To avoid this mistake, just use JSObject&.

Comment 2

[Masatoshi Kimura [:emk]]

Taking.

Comment 3

[Masatoshi Kimura [:emk]]

Attachment: Support default values for Web IDL dictionaries

PCOM interfaces will no longer be created for dictionaries.

Comment 4

[Masatoshi Kimura [:emk]]

Attachment: Implement Blob constructor

Comment 5

[Masatoshi Kimura [:emk]]

Attachment: Tests

Comment 6

[Masatoshi Kimura [:emk]]

Attachment: Example .h

Comment 7

[Masatoshi Kimura [:emk]]

Attachment: Example .cpp

Comment 8

[Masatoshi Kimura [:emk]]

https://tbpl.mozilla.org/?tree=Try&rev=a0591c80535b

Comment 9

[Masatoshi Kimura [:emk]]

Attachment: Implement Blob constructor, v2

Flatten on .Append() so that multipart blobs will never nest.

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 594450 [details]
Example .h

>class BlobPropertyBag
>{
>public:
>  BlobPropertyBag() :
>    type(EmptyString()),

This feels really weird to me. If people feel that it's very important to explicitly initialize every single member, I'm OK with this, but I feel that it'd be much cleaner to not explicitly initialize nsAutoStrings to the empty string.

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 594452 [details]
Example .cpp

>DefineStaticJSVal(JSContext* aCx, jsid &id, const char* aString)

Nit: Define isn't the right verb here. How about "Intern" or "Initialize" instead?

>EventInit_InitInternal(EventInit& aDict, JSContext* aCx, JSObject* aObj)
>{
...
>    NS_ENSURE_STATE(JS_GetPropertyById(aCx, aObj, gDictionary_id_bubbles, &v));
>    JSBool b;
>    JS_ValueToBoolean(aCx, v, &b);

JS_ValueToBoolean can fail, we need to check for a false return value and propagate failure if so.

>    NS_ENSURE_STATE(XPCConvert::JSData2Native(ccx, (void**) getter_AddRefs(aDict.detail), v, nsXPTType(TD_INTERFACE_TYPE), true, &NS_GET_IID(nsIVariant), nsnull));

If it's too hard to change, I'd be OK with this, but I'm wondering if these calls can't use the much cleaner (and more type safe) variants seen in XPCQuickStubs.h. That might also be faster, as those are templated and therefore avoid at least some work.

One thing I'm not entirely sure about is whether or not the string types are going to be as easy to use.

Comment 12

[Masatoshi Kimura [:emk]]

(In reply to Blake Kaplan (:mrbkap) from comment #11)
> JS_ValueToBoolean can fail, we need to check for a false return value and
> propagate failure if so.
Hm, JSData2Native doesn't check the error for boolean values. Is this a bug?
http://hg.mozilla.org/mozilla-central/file/ca84ab42bd5b/js/xpconnect/src/XPCConvert.cpp#l481

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Oops, sorry, JS_ValueToBoolean always returns true. I'd forgotten, you can ignore that comment.

Comment 14

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Wrap it in MOZ_ALWAYS_TRUE(), perhaps

Comment 15

[Masatoshi Kimura [:emk]]

Attachment: Support default values for Web IDL dictionaries, v2

Updated per review comments.

Comment 16

[Masatoshi Kimura [:emk]]

Attachment: Example .h; r=mrbkap

Comment 17

[Masatoshi Kimura [:emk]]

Attachment: Example .cpp, v2

> This feels really weird to me. If people feel that it's very important to explicitly initialize every single member, I'm OK with this, but I feel that it'd be much cleaner to not explicitly initialize nsAutoStrings to the empty string.
I have no strong opinion about those initial values, so removed explicit "EmptyString()".

> Nit: Define isn't the right verb here. How about "Intern" or "Initialize" instead?
I employed "Intern".

> If it's too hard to change, I'd be OK with this, but I'm wondering if these calls can't use the much cleaner (and more type safe) variants seen in XPCQuickStubs.h. That might also be faster, as those are templated and therefore avoid at least some work.
Switched from JSData2Native to quickstub functions. Now XPCCallContext will be declared only when nsIVariant member is present.

Comment 18

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 596036 [details]
Example .cpp, v2

>DefineStaticDictionaryJSVals(JSContext* aCx)

Last nit: This should also be "Intern".

Looks good to me with that.

Comment 19

[Masatoshi Kimura [:emk]]

Attachment: Support default values for Web IDL dictionaries, v2.1

Comment 20

[Masatoshi Kimura [:emk]]

Attachment: Support default values for Web IDL dictionaries, v3

The previous patch caused mochitest-1 failure.

Comment 21

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 594449 [details] [diff] [review]
Tests

Review of attachment 594449 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/base/test/fileutils.js
@@ +101,1 @@
>             "[XHR] no error in test " + testName);

Fix indentation on the second line.

::: content/base/test/test_blobbuilder.html
@@ +142,2 @@
>      // Test type coercion of a number
> +    [[3, aB, "foo"], {},    [{start: 0, length: 8, contents:  "3ABCDEFG"},

Also add a test which tests that line-endings are transparent even when no second argument was passed to the ctor.

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is there a reason you're going through the trouble of flattening multipart blobs?

Comment 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 594978 [details] [diff] [review]
Implement Blob constructor, v2

Review of attachment 594978 [details] [diff] [review]:
-----------------------------------------------------------------

r- to figure out what we want to do with nsIMultipartBlob. I.e. one of:

* Rewrite as .h file and fix QI
* Change to being a simple virtual function on nsDOMFileBase
* Get rid of flattening completely

::: content/base/public/nsIDOMFile.idl
@@ +114,5 @@
> +interface nsIMultipartBlob : nsISupports
> +{
> +%{C++
> +  virtual const nsTArray<nsCOMPtr<nsIDOMBlob> >&
> +  GetSubBlobs() const = 0;

Adding virtual functions in a %{C++%}-block is very fragile. Any scriptable functions added after it will break since we'll call the wrong entry in the vtable.

Instead make this interface a non-scriptable .h interface, probably declared directly in the nsDOMBlobBuilder.cpp file.

Another option is to cast every blob to nsDOMFileBase and add to that class as a function like 

virtual const nsTArray<...>* GetSubBlobs() { return nsnull; }

and then override only in the multipart implementation.

::: content/base/src/nsDOMBlobBuilder.cpp
@@ +48,5 @@
>  
>  using namespace mozilla;
>  
> +NS_IMPL_ISUPPORTS_INHERITED1(nsDOMMultipartFile, nsDOMFileBase,
> +                             nsIJSNativeInitializer)

Don't you need to add nsIMultipartBlob to the QI (assuming we keep that interface)?

I suspect the flattening code is never actually running right now since the QI will always fail. Which makes me wonder why bother with flattening at all?

@@ +189,5 @@
> +  if (aArgc > 1) {
> +    mozilla::dom::BlobPropertyBag d;
> +    nsresult rv = d.Init(aCx, &aArgv[1]);
> +    NS_ENSURE_SUCCESS(rv, rv);
> +    mContentType = d.type;

Make sure that mContentType is never set to a void string here. You need to either call mContentType.SetIsVoid(false) after the assignment, or even more correct, make sure that the dictionary parser never produces a void string unless the type in the dictionary is "DOMString?"

Comment 24

[Masatoshi Kimura [:emk]]

(In reply to Jonas Sicking (:sicking) from comment #22)
> Is there a reason you're going through the trouble of flattening multipart
> blobs?
I imagined a use case such as [1].
Nests will become deeper and deeper everytime the constructor is called if we do not flatten the blob.

[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0464.html

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ok, fair enough. But do fix it one way or another (my preference is the plain virtual function on the base class) since right now the patch doesn't flatten at all.

Comment 26

[Masatoshi Kimura [:emk]]

Attachment: Support default values for Web IDL dictionaries, v4

Changed nullBehavior and undefinedBehavior to ensure that a void string will never be produced.
I will not implement "T?" types support to the dictionary parser right now.

Comment 27

[Masatoshi Kimura [:emk]]

Attachment: Implement Blob constructor, v3

I added a virtual function on nsDOMFileBase.

Comment 28

[Masatoshi Kimura [:emk]]

Attachment: Test, v2; r=jonas

I also added tests for stringification behaviors to null and undefined values in the dictionary.

Comment 29

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 596321 [details] [diff] [review]
Implement Blob constructor, v3

Review of attachment 596321 [details] [diff] [review]:
-----------------------------------------------------------------

This is awesome!

Comment 30

[Masatoshi Kimura [:emk]]

Attachment: Test, v2.1; r=jonas

Rebased to tip

Comment 31

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I have been a little busy, I will review the patch this weekend.

Comment 32

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 596320 [details] [diff] [review]
Support default values for Web IDL dictionaries, v4

Review of attachment 596320 [details] [diff] [review]:
-----------------------------------------------------------------

I don't entirely understand this patch.  What does the generated stuff for a dictionary look like?  Is it still an XPIDL interface?

Comment 33

[Masatoshi Kimura [:emk]]

> What does the generated stuff for a dictionary look like?
See attached Example .h/.cpp.
> Is it still an XPIDL interface?
No. I think XPIDL interface is redundant because dictionaries are only convenience for C++ codes. It uses JSAPI directly to initialize the value.

Comment 34

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Masatoshi Kimura [:emk] from comment #33)
> > What does the generated stuff for a dictionary look like?
> See attached Example .h/.cpp.
> > Is it still an XPIDL interface?
> No. I think XPIDL interface is redundant because dictionaries are only
> convenience for C++ codes. It uses JSAPI directly to initialize the value.

Ok, so it just generates a struct or something?

Comment 35

[Masatoshi Kimura [:emk]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #34)
> (In reply to Masatoshi Kimura [:emk] from comment #33)
> > > What does the generated stuff for a dictionary look like?
> > See attached Example .h/.cpp.
> > > Is it still an XPIDL interface?
> > No. I think XPIDL interface is redundant because dictionaries are only
> > convenience for C++ codes. It uses JSAPI directly to initialize the value.
> 
> Ok, so it just generates a struct or something?
Yeah, it generates a class with public members and Initialize method.

Comment 36

[Masatoshi Kimura [:emk]]

Attachment: Test, v2.2; r=jonas

Updated to tip

Comment 37

[Masatoshi Kimura [:emk]]

Attachment: Support default values for Web IDL dictionaries, v4.1

Rebased to tip

Comment 38

[Masatoshi Kimura [:emk]]

Attachment: Implement Blob constructor, v3.1; r=jonas

Rebased to tip

Comment 39

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Kyle: Review ping? Would be great to get this in by the 13th.

Comment 40

[Masatoshi Kimura [:emk]]

I'll have to update a patch to incorporate StorageEvent constructor (bug 730891).

Comment 41

[Masatoshi Kimura [:emk]]

Attachment: Support default values for Web IDL dictionaries, v4.2

Updated to tip

Comment 42

[Masatoshi Kimura [:emk]]

Attachment: Implement Blob constructor, v3.2; r=jonas

Updated to tip

Comment 43

[Mozilla RelEng Bot]

Autoland Patchset:
	Patches: 604401, 604402, 600761
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/pushloghtml?changeset=e1868b23d67d
Try run started, revision e1868b23d67d. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=e1868b23d67d

Comment 44

[Mozilla RelEng Bot]

Try run for e1868b23d67d is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=e1868b23d67d
Results (out of 14 total builds):
    success: 14
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-e1868b23d67d

Comment 45

[Masatoshi Kimura [:emk]]

Ugh, unit tests haven't run.

Comment 46

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Jonas Sicking (:sicking) from comment #39)
> Kyle: Review ping? Would be great to get this in by the 13th.

I want to get this in too, but it's scary, security-sensitive code that has to be reviewed carefully.  I hope to finish this weekend.

Comment 47

[Mozilla RelEng Bot]

Autoland Patchset:
	Patches: 604401, 604402, 600761
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/pushloghtml?changeset=e3e230041ba4
Try run started, revision e3e230041ba4. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=e3e230041ba4

Comment 48

[Masatoshi Kimura [:emk]]

Attachment: Implement nullable types support

I added a support for "DOMString?" type because it is used by StorageEventInit.
Explicit SetIsVoid calls are no longer needed.

Comment 49

[Mozilla RelEng Bot]

Try run for e3e230041ba4 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=e3e230041ba4
Results (out of 216 total builds):
    success: 179
    warnings: 36
    failure: 1
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-e3e230041ba4

Comment 50

[Mozilla RelEng Bot]

Autoland Patchset:
	Patches: 604401, 604402, 600761, 604592
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/pushloghtml?changeset=538bca875681
Try run started, revision 538bca875681. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=538bca875681

Comment 51

[Mozilla RelEng Bot]

Try run for 538bca875681 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=538bca875681
Results (out of 202 total builds):
    exception: 3
    success: 161
    warnings: 37
    failure: 1
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-538bca875681

Comment 52

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 604401 [details] [diff] [review]
Support default values for Web IDL dictionaries, v4.2

Review of attachment 604401 [details] [diff] [review]:
-----------------------------------------------------------------

I'm terrified of the change, but I can't find anything wrong.

Comment 53

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I don't think these patches apply.  I tried to build with them and didn't succeed.

Comment 54

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'll try to merge and land this tonight. But any help with merging would be greatly appreciated.

Comment 55

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

After the uplift, I hope?

Comment 56

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Comment on attachment 604401 [details] [diff] [review]
Support default values for Web IDL dictionaries, v4.2

>--- a/content/events/test/test_eventctors.html
>+++ b/content/events/test/test_eventctors.html
>-// StorageEvent
>+// UIEvent
> 
> try {
>-  e = new StorageEvent();
>-} catch(exp) {
>-  ex = true;
>-}
>-ok(ex, "First parameter is required!");
>-ex = false;
>-
>-e = new StorageEvent("hello");
>-ok(e.type, "hello", "Wrong event type!");
>-ok(!e.isTrusted, "Event shouldn't be trusted!");
>-ok(!e.bubbles, "Event shouldn't bubble!");
>-ok(!e.cancelable, "Event shouldn't be cancelable!");
>-is(e.key, "", "key should be ''");
>-is(e.oldValue, null, "oldValue should be null");
>-is(e.newValue, null, "newValue should be null");
>-is(e.url, "", "url should be ''");
>-document.dispatchEvent(e);
>-is(receivedEvent, e, "Wrong event!");
>-
>-e = new StorageEvent("hello",
>-  { bubbles: true, cancelable: true, key: "key",
>-    oldValue: "oldValue", newValue: "newValue", url: "url",
>-    storageArea: localStorage });
>-ok(e.type, "hello", "Wrong event type!");
>-ok(!e.isTrusted, "Event shouldn't be trusted!");
>-ok(e.bubbles, "Event should bubble!");
>-ok(e.cancelable, "Event should be cancelable!");
>-is(e.key, "key", "Wrong value");
>-is(e.oldValue, "oldValue", "Wrong value");
>-is(e.newValue, "newValue", "Wrong value");
>-is(e.url, "url", "Wrong value");
>-is(e.storageArea, localStorage, "Wrong value");
>-document.dispatchEvent(e);
>-is(receivedEvent, e, "Wrong event!");
>-
>-// MouseEvent
>-
>-try {
>-  e = new MouseEvent();
>+  e = new UIEvent();

Where did these tests go?

Comment 57

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

https://hg.mozilla.org/mozilla-central/rev/4d64d2d31843
https://hg.mozilla.org/mozilla-central/rev/c7f4e6a7f627
https://hg.mozilla.org/mozilla-central/rev/95a8eba120fe
https://hg.mozilla.org/mozilla-central/rev/1ca7a94573f2

Masatoshi-san, could you answer comment 56? Sorry if I missed something during review. If we for some reason didn't need the tests then that's ok.

Comment 58

[Masatoshi Kimura [:emk]]

(In reply to Ms2ger from comment #56)
> Where did these tests go?
My bad. I should have updated the test so that it includes StorageEvent test.

Comment 59

[Frederic Bezies]

Sorry to spam this bug, but since this patch was applied, I cannot get thunderbird to be build on my archlinux 64 bits (sorry, long text) :

Traceback (most recent call last):
  File "/home/fred/logs/mail/src/mozilla/config/pythonpath.py", line 52, in <module>
    main(sys.argv[1:])
  File "/home/fred/logs/mail/src/mozilla/config/pythonpath.py", line 44, in main
    execfile(script, frozenglobals)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/header.py", line 531, in <module>
    idl.resolve(options.incdirs, p)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 318, in resolve
    p.resolve(self)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 281, in resolve
    self.IDL = parent.parser.parse(open(file).read(), filename=file)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 1592, in parse
    idl = self.parser.parse(lexer=self)
  File "/home/fred/logs/mail/src/mozilla/other-licenses/ply/ply/yacc.py", line 265, in parse
Traceback (most recent call last):
  File "/home/fred/logs/mail/src/mozilla/config/pythonpath.py", line 52, in <module>
    main(sys.argv[1:])
  File "/home/fred/logs/mail/src/mozilla/config/pythonpath.py", line 44, in main
    execfile(script, frozenglobals)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/header.py", line 531, in <module>
    idl.resolve(options.incdirs, p)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 318, in resolve
    p.resolve(self)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 281, in resolve
    self.IDL = parent.parser.parse(open(file).read(), filename=file)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 1592, in parse
    idl = self.parser.parse(lexer=self)
  File "/home/fred/logs/mail/src/mozilla/other-licenses/ply/ply/yacc.py", line 265, in parse
    return self.parseopt_notrack(input,lexer,debug,tracking,tokenfunc)
  File "/home/fred/logs/mail/src/mozilla/other-licenses/ply/ply/yacc.py", line 1047, in parseopt_notrack
    return self.parseopt_notrack(input,lexer,debug,tracking,tokenfunc)
  File "/home/fred/logs/mail/src/mozilla/other-licenses/ply/ply/yacc.py", line 1047, in parseopt_notrack
    tok = self.errorfunc(errtoken)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 1563, in p_error
    raise IDLError("invalid syntax", location)
xpidl.IDLError: error: invalid syntax, /home/fred/logs/mail/src/mozilla/dom/interfaces/events/nsIDOMEvent.idl line 185:0
dictionary EventInit
^
    tok = self.errorfunc(errtoken)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 1563, in p_error
    raise IDLError("invalid syntax", location)
xpidl.IDLError: error: invalid syntax, /home/fred/logs/mail/src/mozilla/dom/interfaces/events/nsIDOMEvent.idl line 185:0
dictionary EventInit
^
nsIDOMDragEvent.idl
make[4]: *** [_xpidlgen/nsIDOMMutationEvent.h] Erreur 1
make[4]: *** Suppression du fichier « _xpidlgen/nsIDOMMutationEvent.h »
make[4]: *** Attente des tâches non terminées....
make[4]: *** [_xpidlgen/nsIDOMDataContainerEvent.h] Erreur 1
make[4]: *** Suppression du fichier « _xpidlgen/nsIDOMDataContainerEvent.h »
Traceback (most recent call last):
  File "/home/fred/logs/mail/src/mozilla/config/pythonpath.py", line 52, in <module>
    main(sys.argv[1:])
  File "/home/fred/logs/mail/src/mozilla/config/pythonpath.py", line 44, in main
    execfile(script, frozenglobals)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/header.py", line 531, in <module>
    idl.resolve(options.incdirs, p)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 318, in resolve
    p.resolve(self)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 281, in resolve
    self.IDL = parent.parser.parse(open(file).read(), filename=file)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 1592, in parse
    idl = self.parser.parse(lexer=self)
  File "/home/fred/logs/mail/src/mozilla/other-licenses/ply/ply/yacc.py", line 265, in parse
    return self.parseopt_notrack(input,lexer,debug,tracking,tokenfunc)
  File "/home/fred/logs/mail/src/mozilla/other-licenses/ply/ply/yacc.py", line 1047, in parseopt_notrack
    tok = self.errorfunc(errtoken)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 1563, in p_error
    raise IDLError("invalid syntax", location)
xpidl.IDLError: error: invalid syntax, /home/fred/logs/mail/src/mozilla/dom/interfaces/events/nsIDOMUIEvent.idl line 77:0
dictionary UIEventInit : EventInit
^
make[4]: *** [_xpidlgen/nsIDOMKeyEvent.h] Erreur 1
make[4]: *** Suppression du fichier « _xpidlgen/nsIDOMKeyEvent.h »
Traceback (most recent call last):
  File "/home/fred/logs/mail/src/mozilla/config/pythonpath.py", line 52, in <module>
    main(sys.argv[1:])
  File "/home/fred/logs/mail/src/mozilla/config/pythonpath.py", line 44, in main
    execfile(script, frozenglobals)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/header.py", line 531, in <module>
    idl.resolve(options.incdirs, p)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 318, in resolve
    p.resolve(self)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 281, in resolve
    self.IDL = parent.parser.parse(open(file).read(), filename=file)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 1592, in parse
    idl = self.parser.parse(lexer=self)
  File "/home/fred/logs/mail/src/mozilla/other-licenses/ply/ply/yacc.py", line 265, in parse
    return self.parseopt_notrack(input,lexer,debug,tracking,tokenfunc)
  File "/home/fred/logs/mail/src/mozilla/other-licenses/ply/ply/yacc.py", line 1047, in parseopt_notrack
    tok = self.errorfunc(errtoken)
  File "/home/fred/logs/mail/src/mozilla/xpcom/idl-parser/xpidl.py", line 1563, in p_error
    raise IDLError("invalid syntax", location)
xpidl.IDLError: error: invalid syntax, /home/fred/logs/mail/src/mozilla/dom/interfaces/events/nsIDOMMouseEvent.idl line 117:0
dictionary MouseEventInit : UIEventInit
^
make[4]: *** [_xpidlgen/nsIDOMDragEvent.h] Erreur 1
make[4]: *** Suppression du fichier « _xpidlgen/nsIDOMDragEvent.h »
make[3]: *** [export] Erreur 2
make[2]: *** [export] Erreur 2
make[1]: *** [export] Erreur 2
make: *** [depend] Erreur 2

Comment 60

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Pull mozilla-central again, it should be fixed.

Comment 61

[Frederic Bezies]

No, it is not. I opened bug 735434 related to this bustage.

Comment 62

[Olli Pettay [:smaug][[e-mail]]]

So the patch broken floats and doubles in dictionaries.

Comment 63

[Eric Shepherd [:sheppy]]

Docs already updated:

https://developer.mozilla.org/en/DOM/Blob

Mentioned on Firefox 13 for developers.

Comment 64

[[e-mail]]

Comment on attachment 604401 [details] [diff] [review]
Support default values for Web IDL dictionaries, v4.2

>+        fd.write("    nsCOMPtr<nsIVariant> d(already_AddRefed<nsIVariant>(XPCVariant::newVariant(ccx, v)));\n")
We have a template for this. You should write something like:
fd.write("    nsCOMPtr<nsIVariant> d(dont_AddRef(XPCVariant::newVariant(ccx, v)));\n")