Open Bug 1161728 Opened 9 years ago Updated 1 year ago
Error: this .doc Shell is undefined on xul editor element
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
[Tracking Requested - why for this release]:
Tim fixed this today in a different bug.
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
(FYI, I noticed the problem when I tested Bug 1143570)
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...
(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 ?
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).
This hasn't been touched for a while, and doesn't seem severe enough for ESR tracking.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.