Blob should have a constructor.

RESOLVED FIXED in mozilla13

Status

()

defect
RESOLVED FIXED
7 years ago
2 months ago

People

(Reporter: sicking, Assigned: emk)

Tracking

({dev-doc-complete})

Trunk
mozilla13
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(6 attachments, 15 obsolete attachments)

4.21 KB, text/plain
emk
: review+
Details
19.30 KB, text/plain
mrbkap
: review+
Details
19.77 KB, patch
Details | Diff | Splinter Review
39.97 KB, patch
khuey
: review+
Details | Diff | Splinter Review
16.83 KB, patch
emk
: review+
Details | Diff | Splinter Review
8.49 KB, patch
khuey
: review+
Details | Diff | Splinter Review
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.
    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&.
Assignee

Comment 2

7 years ago
Taking.
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Depends on: 720208, 723894
Assignee

Comment 3

7 years ago
PCOM interfaces will no longer be created for dictionaries.
Attachment #594447 - Flags: review?(khuey)
Assignee

Comment 4

7 years ago
Posted patch Implement Blob constructor (obsolete) — Splinter Review
Attachment #594448 - Flags: review?(jonas)
Assignee

Comment 5

7 years ago
Posted patch Tests (obsolete) — Splinter Review
Attachment #594449 - Flags: review?(jonas)
Assignee

Comment 6

7 years ago
Posted file Example .h (obsolete) —
Attachment #594450 - Flags: review?(mrbkap)
Assignee

Comment 7

7 years ago
Posted file Example .cpp (obsolete) —
Attachment #594452 - Flags: review?(mrbkap)
Assignee

Updated

7 years ago
Attachment #594452 - Attachment is patch: false
Assignee

Comment 9

7 years ago
Flatten on .Append() so that multipart blobs will never nest.
Attachment #594448 - Attachment is obsolete: true
Attachment #594448 - Flags: review?(jonas)
Attachment #594978 - Flags: review?(jonas)
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.
Attachment #594450 - Flags: review?(mrbkap) → review+
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.
Attachment #594452 - Flags: review?(mrbkap)
Assignee

Comment 12

7 years ago
(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
Oops, sorry, JS_ValueToBoolean always returns true. I'd forgotten, you can ignore that comment.
Wrap it in MOZ_ALWAYS_TRUE(), perhaps
Assignee

Comment 15

7 years ago
Updated per review comments.
Attachment #594447 - Attachment is obsolete: true
Attachment #594447 - Flags: review?(khuey)
Attachment #596030 - Flags: review?(khuey)
Assignee

Comment 16

7 years ago
Attachment #594450 - Attachment is obsolete: true
Attachment #596031 - Flags: review+
Assignee

Comment 17

7 years ago
Posted file 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.
Attachment #594452 - Attachment is obsolete: true
Attachment #596036 - Flags: review?(mrbkap)
Comment on attachment 596036 [details]
Example .cpp, v2

>DefineStaticDictionaryJSVals(JSContext* aCx)

Last nit: This should also be "Intern".

Looks good to me with that.
Attachment #596036 - Flags: review?(mrbkap) → review+
Assignee

Comment 19

7 years ago
Attachment #594978 - Attachment is obsolete: true
Attachment #594978 - Flags: review?(jonas)
Attachment #596045 - Flags: review?(khuey)
Assignee

Updated

7 years ago
Attachment #596045 - Attachment is patch: true
Assignee

Comment 20

7 years ago
The previous patch caused mochitest-1 failure.
Attachment #596030 - Attachment is obsolete: true
Attachment #596045 - Attachment is obsolete: true
Attachment #596030 - Flags: review?(khuey)
Attachment #596045 - Flags: review?(khuey)
Attachment #596271 - Flags: review?(khuey)
Assignee

Updated

7 years ago
Attachment #594978 - Attachment is obsolete: false
Attachment #594978 - Flags: review?(jonas)
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.
Attachment #594449 - Flags: review?(jonas) → review+
Is there a reason you're going through the trouble of flattening multipart blobs?
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?"
Attachment #594978 - Flags: review?(jonas) → review-
Assignee

Comment 24

7 years ago
(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
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.
Assignee

Comment 26

7 years ago
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.
Attachment #596271 - Attachment is obsolete: true
Attachment #596271 - Flags: review?(khuey)
Attachment #596320 - Flags: review?(khuey)
Assignee

Comment 27

7 years ago
I added a virtual function on nsDOMFileBase.
Attachment #594978 - Attachment is obsolete: true
Attachment #596321 - Flags: review?(jonas)
Assignee

Comment 28

7 years ago
Posted patch Test, v2; r=jonas (obsolete) — Splinter Review
I also added tests for stringification behaviors to null and undefined values in the dictionary.
Attachment #594449 - Attachment is obsolete: true
Attachment #596322 - Flags: review+
Comment on attachment 596321 [details] [diff] [review]
Implement Blob constructor, v3

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

This is awesome!
Attachment #596321 - Flags: review?(jonas) → review+
Assignee

Comment 30

7 years ago
Posted patch Test, v2.1; r=jonas (obsolete) — Splinter Review
Rebased to tip
Attachment #596322 - Attachment is obsolete: true
I have been a little busy, I will review the patch this weekend.
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?
Assignee

Comment 33

7 years ago
> 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.
(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?
Assignee

Comment 35

7 years ago
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) 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.
Assignee

Comment 36

7 years ago
Updated to tip
Attachment #598206 - Attachment is obsolete: true
Assignee

Comment 37

7 years ago
Rebased to tip
Attachment #596320 - Attachment is obsolete: true
Attachment #596320 - Flags: review?(khuey)
Attachment #601568 - Flags: review?(khuey)
Assignee

Comment 38

7 years ago
Rebased to tip
Attachment #596321 - Attachment is obsolete: true
Attachment #602317 - Flags: review+
Kyle: Review ping? Would be great to get this in by the 13th.
Assignee

Comment 40

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

Comment 41

7 years ago
Updated to tip
Attachment #601568 - Attachment is obsolete: true
Attachment #601568 - Flags: review?(khuey)
Attachment #604401 - Flags: review?(khuey)
Assignee

Comment 42

7 years ago
Updated to tip
Attachment #602317 - Attachment is obsolete: true
Attachment #604402 - Flags: review+
Assignee

Updated

7 years ago
Whiteboard: [autoland-try:604401,604402,600761]

Updated

7 years ago
Whiteboard: [autoland-try:604401,604402,600761] → [autoland-in-queue]
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
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/autolanduser@mozilla.com-e1868b23d67d

Updated

7 years ago
Whiteboard: [autoland-in-queue]
Assignee

Comment 45

7 years ago
Ugh, unit tests haven't run.
Whiteboard: [autoland-try:604401,604402,600761:-b do -p all -u none]
Assignee

Updated

7 years ago
Whiteboard: [autoland-try:604401,604402,600761:-b do -p all -u none]
Assignee

Updated

7 years ago
Whiteboard: [autoland-try:604401,604402,600761:-b do -p all -u all]
(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.

Updated

7 years ago
Whiteboard: [autoland-try:604401,604402,600761:-b do -p all -u all] → [autoland-in-queue]
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
Assignee

Comment 48

7 years ago
I added a support for "DOMString?" type because it is used by StorageEventInit.
Explicit SetIsVoid calls are no longer needed.
Attachment #604592 - Flags: review?(khuey)
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/autolanduser@mozilla.com-e3e230041ba4

Updated

7 years ago
Whiteboard: [autoland-in-queue]
Assignee

Updated

7 years ago
Whiteboard: [autoland-try:604401,604402,600761,604592:-b do -p all -u all -t none]

Updated

7 years ago
Whiteboard: [autoland-try:604401,604402,600761,604592:-b do -p all -u all -t none] → [autoland-in-queue]
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
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/autolanduser@mozilla.com-538bca875681

Updated

7 years ago
Whiteboard: [autoland-in-queue]
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.
Attachment #604401 - Flags: review?(khuey) → review+
Assignee

Updated

7 years ago
Keywords: checkin-needed
I don't think these patches apply.  I tried to build with them and didn't succeed.
Keywords: checkin-needed
I'll try to merge and land this tonight. But any help with merging would be greatly appreciated.
After the uplift, I hope?
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?
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Assignee

Comment 58

7 years ago
(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.
Assignee

Updated

7 years ago
Depends on: 735268

Comment 59

7 years ago
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
Pull mozilla-central again, it should be fixed.

Comment 61

7 years ago
No, it is not. I opened bug 735434 related to this bustage.
Target Milestone: --- → mozilla13
Assignee

Updated

7 years ago
Depends on: 736686
Assignee

Updated

7 years ago
Depends on: 736687
Assignee

Updated

7 years ago
Depends on: 736804
Assignee

Updated

7 years ago
Depends on: 736805
Assignee

Updated

7 years ago
Depends on: 738966
So the patch broken floats and doubles in dictionaries.
Depends on: 739760
Depends on: 745147
Docs already updated:

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

Mentioned on Firefox 13 for developers.
Assignee

Updated

7 years ago
Depends on: 752402
Depends on: 777888
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")

Updated

6 years ago
Depends on: 851469
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.