Closed Bug 590870 Opened 11 years ago Closed 11 years ago

Crash attempting to create remote XUL element [@ nsDocument::CreateElementNS ]

Categories

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

defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: neil, Assigned: sicking)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(3 files)

Steps to reproduce problem:
1. Try to create an element in the XUL namespace

Gecko 0.x/1.x result: [object XULElement]

Actual result: Crash
Depends on: 355451, kill-remote-xul
Duplicate of this bug: 590858
bp-9d5c9d39-b1e1-4345-a7eb-d6d972100826
Summary: Crash attempting to create remote XUL element → Crash attempting to create remote XUL element [@ nsDocument::CreateElementNS ]
Flags: in-testsuite?
(In reply to comment #2)
> bp-9d5c9d39-b1e1-4345-a7eb-d6d972100826

Related crash bp-271889eb-f486-4dfa-9315-c17102100826 is averted by ensuring the createElementNS method is called upon the xul document into which the element is to inserted rather than (erroneously) upon the content document.createElementNS of some recently loaded webpage.
Assignee: nobody → jonas
blocking2.0: --- → beta5+
No longer depends on: kill-remote-xul
Duplicate of this bug: 590642
Attached patch Should fix itSplinter Review
Obvious fix. I'll add a testcase as well.
Attachment #470092 - Flags: review?(jst)
Comment on attachment 470092 [details] [diff] [review]
Should fix it

r=jst :)
Attachment #470092 - Flags: review?(jst) → review+
Fixed friday night:

http://hg.mozilla.org/mozilla-central/rev/1fe5a5c22b0f
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Fixed friday night:

http://hg.mozilla.org/mozilla-central/rev/567c0e5bf04e

However I need to figure out a way to test this. We should probably set up a domain which doesn't support XUL.

Leaving as assigned to remind me to check in a test.
blocking2.0: beta5+ → beta6+
Please ignore comment 8, it relates to another bug.
blocking2.0: beta6+ → beta5+
Gonna reopen this to get attention to the review requests though.
Status: RESOLVED → REOPENED
blocking2.0: beta5+ → betaN+
Resolution: FIXED → ---
Attachment #470962 - Flags: review?(jst) → review+
Comment on attachment 470961 [details] [diff] [review]
Tests patch 1. Allow XUL support on a site-by-site basis in mochitest

>diff --git a/build/automation.py.in b/build/automation.py.in
>--- a/build/automation.py.in
>+++ b/build/automation.py.in
>@@ -302,37 +302,38 @@ class Automation(object):
>        type TEXT,
>        permission INTEGER,
>        expireType INTEGER,
>        expireTime INTEGER)""")
> 
>     # Insert desired permissions
>     c = 0
>     for perm in permissions.keys():
>-      for host in permissions[perm]:
>+      for (host,allow) in permissions[perm]:

You don't need the parentheses here.

>     # Set up permissions database
>     locations = self.readLocations()
>     self.setupPermissionsDatabase(profileDir,
>-      {'allowXULXBL':map(lambda l: l.host, locations)});
>+      {'allowXULXBL':map(lambda l: (l.host, 'noxul' not in l.options),
>+                         locations)});

I missed this last time, but this would be better written as a list comprehension:
{'allowXULXBL':[(l.host, 'noxul' not in l.options) for l in locations]}

r=me with those changes.
Attachment #470961 - Flags: review?(ted.mielczarek) → review+
Checked in to m-c

http://hg.mozilla.org/mozilla-central/rev/52f58de5bd35
http://hg.mozilla.org/mozilla-central/rev/7f98e06f680d
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Crash Signature: [@ nsDocument::CreateElementNS ]
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.