1161728 - Error: TypeError: this.docShell is undefined on xul editor element

Status: NEW

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

Description

[Alice0775 White]

Attachment: editor.xul

Just test xul editor element ( https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/editor )

editor element fails to initialize with an error.
This problem happens since Firefox36.

Steps To Reproduce:
1. Make sure allow remote XUL <file> and/or "mozilla.org"
2. Open Attached xul file
3. Click rectangle area
4. Type keyboard

Actual Results:
Nothing happens.
The following error in error console:

Error: TypeError: this.docShell is undefined
Source File: chrome://global/content/bindings/editor.xml
Line: 132

Expected Results:
Caret should appear.
Text should appear.

Regression window
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c3099024c40a&tochange=8d3304b7e0e0

Triggered by: Bug 979835

Comment 1

[Alice0775 White]

[Tracking Requested - why for this release]:

Comment 2

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

Tim fixed this today in a different bug.

Comment 3

[Alice0775 White]

If you mean Bug 1109875, unfortunately, Bug 1109875 does not fix this.

https://hg.mozilla.org/integration/fx-team/rev/e2cb353f68b7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 ID:20150505074939

Comment 4

[Alice0775 White]

(FYI, I noticed the problem when I tested Bug 1143570)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Bug 979835 made the .docShell attribute on ContainerBoxObject ChromeOnly.  The testcase involved is not being loaded with the system principal, so it can't see that attribute.

I suppose we could make that attribute conditioned on IsChromeOrXBL.  Except I don't think that would help, since iirc we don't use a separate XBL compartment when XUL is force-enabled.  Bobby, is that correct?

I'm not at all happy exposing a docshell to random untrusted script, and see no particular reason to do that if this is only a problem for XUL-loaded-as-not-chrome...

Comment 6

[Bobby Holley (:bholley)]

(In reply to Not doing reviews right now from comment #5)
> I suppose we could make that attribute conditioned on IsChromeOrXBL.  Except
> I don't think that would help, since iirc we don't use a separate XBL
> compartment when XUL is force-enabled.  Bobby, is that correct?

Correct.

> I'm not at all happy exposing a docshell to random untrusted script, and see
> no particular reason to do that if this is only a problem for
> XUL-loaded-as-not-chrome...

Doesn't comment 0 show the source file being chrome://global/content/bindings/editor.xml ?

Comment 7

[Boris Zbarsky [:bzbarsky]]

That's the binding.  But it's being applied to a file:// URI in my case (and in the steps to reproduce in comment 0).

Comment 8

[Kate Glazko]

This hasn't been touched for a while, and doesn't seem severe enough for ESR tracking.