Closed Bug 607325 Opened 12 years ago Closed 4 years ago
_webconsole _bug _594477 _clickable _output .js always fails for me
possible dupe of bug 462238 ?
WFM on changeset c133d3c084c0 32-bit ubuntu 10.04
Also ran entire test suite, WFM. (again, 32 bit linux)
I just ran it locally in an ubuntu 10.04 vm and passed all tests. Mihai, can you paste your .mozconfig in here?
My .mozconfig: . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-obj mk_add_options MOZ_MAKE_FLAGS=-j4 ac_add_options --enable-optimize ac_add_options --enable-tests It's the same .mozconfig I use since I started work in the summer.
STR: 1. Open Firefox (latest nightly should be fine). 2. Open Google.com. 3. Open the Web Console. 4. Refresh the page. 5. Click on a network request. 6. Close the network panel. 7. Evaluate "document" in the Web Console. Expected result: [object HTMLDocument] is displayed, and we can inspect the object. Actual result: I always get: Error: Permission denied for <moz-safe-about:blank> to get property Window.document from <>. Can anyone repro? It is interesting to note that step 7 works fine if you do not open the network panel (step 5 and 6). Bug 602198 introduced this regression. Once I remove type=content on the iframe element, the test runs fine, and the repro steps above also produce the expected result. The clickable output test does precisely what the repro steps above explain in words. I do not think that type=content should cause such a serious regression. I believe this is a Gecko bug/feature at its roots, somehow. Someone more experienced should be CC'ed here, to provide us with further insights.
wfm in OS X - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101031 Firefox/4.0b8pre
Asking Mr. Blake Kaplan for a comment on this bug. On IRC bsmedberg suggested I should do so. Because you may not know the code this bug is talking about ... I am going to try a really quick "crash course": The new Web Console is implemented by the HUDService.jsm. We build the entire XUL UI on demand. User's JS input is evaluated with a Cu.Sandbox() in the context of the currently active tab page window. Please see: http://hg.mozilla.org/mozilla-central/file/39a979e26931/toolkit/components/console/hudservice/HUDService.jsm#l4139 In the console output we log network requests, using some other code. Please see the httpObserver: http://hg.mozilla.org/mozilla-central/file/39a979e26931/toolkit/components/console/hudservice/HUDService.jsm#l2337 When the user clicks a network log message, he's presented with a new xul:panel that holds network request and response information: http://hg.mozilla.org/mozilla-central/file/39a979e26931/toolkit/components/console/hudservice/HUDService.jsm#l2319 http://hg.mozilla.org/mozilla-central/file/39a979e26931/toolkit/components/console/hudservice/HUDService.jsm#l689 That code creates a xul:panel which holds a xul:iframe type=content, appended to the chrome window's #mainPopupSet. All things run fine. Except that ... when the user tries to evaluate something like "document" in the Web Console, it fails after one network panel is open. It looks like, for some reason, the xul:iframe type=content automatically reduces the privilege of the sandbox or ?, which is weird. As I understand, the reduced privilege (see bug 602198), only affects the scripts within the iframe. Could you please tell us what's happening here? Why would the totally unrelated act of appending a xul:iframe type=content ... cause the sandbox to fail? Also, why does this fail only on my system, not in try builds, and not for others? What can I do to investigate this issue further? Thank you! Sorry for this length comment, but I am trying to make the situation clear.
mass change: filter on PRIORITYSETTING
Priority: -- → P3
Problem found: The test fails because I have Gnome accessibility features enabled, and the Firefox accessibility code breaks the test. Once the iframe type=content is displayed ... the Web Console sandbox has issues with its privileges. This happens only when accessibility is enabled, hence nobody was able to repro. I believe this is no longer a devtools bug, thus I am re-assigning the bug to nobody. CC'ing Alexander Surkov who works on accessibility code. Can you please take a look at the comments in this bug and see why accessibility features break something "entirely unrelated"? Thank you!
Assignee: mihai.sucan → nobody
Whiteboard: [needs further investigation]
No any worth idea. I wasn't able to reproduce on windows. What does Web console do for evaluation? Could be permission denied somewhere internally while web console tries to evaluate a document? If so then I would assume at-spi calls into us asking to do something that requires enhanced privileges. A11y should fire an event synchronously to at-spi to make that happen I think. We still have several places when we fire events in sync so I would start investigation from this point. cc'ing Fernando.
(In reply to comment #11) > No any worth idea. I wasn't able to reproduce on windows. What does Web console > do for evaluation? I have Linux, so please test on Linux - I can't say it's a cross-platform bug. ;) We use Components.utils.evalInSandox() to evaluate the user input. The sandbox object is created with Components.utils.Sandbox(). See: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/console/hudservice/HUDService.jsm#3985 and http://mxr.mozilla.org/mozilla-central/source/toolkit/components/console/hudservice/HUDService.jsm#4008 > Could be permission denied somewhere internally while web > console tries to evaluate a document? If so then I would assume at-spi calls > into us asking to do something that requires enhanced privileges. A11y should > fire an event synchronously to at-spi to make that happen I think. We still > have several places when we fire events in sync so I would start investigation > from this point. Indeed, that is possible, but I wonder why does an iframe of lower privileges (type=content) affect the sandbox? The sandbox lives outside the network panel iframe. There's no link between the two, except the parent code that created both of them. Without accessibility enabled, things work as expected - the iframe doesn't affect the sandbox. Perhaps the accessibility code causes the sandbox to lower its privileges when the iframe type=content is created.
(In reply to comment #12) > Perhaps the accessibility code causes the > sandbox to lower its privileges when the iframe type=content is created. Can we get someone who knows about security for ideas or point possible reasons?
Mihai: have you seen this problem lately?
Whiteboard: [needs further investigation] → [needs further investigation] [console-3]
David: this is no longer a devtools problem. It's a bug with accessibility code, IIANM. I have since then disabled my Gnome accessibility features - they were also causing important Firefox slowdowns.
Changed component to "Disability Access."
Component: Developer Tools → Disability Access
QA Contact: developer.tools → disability.access
Test does not exist anymore
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.