607325 - Test browser_webconsole_bug_594477_clickable_output.js always fails for me

Status: RESOLVED INVALID

(Firefox :: Disability Access, defect, P3)

Description

[Mihai Sucan [:msucan]]

Since the compartments code landed the Web Console test browser_webconsole_bug_594477_clickable_output.js always fails pretty badly for me. Whenever it tries to execute "document" it gets permission denied:

> document
18:10:48.431: Error: Permission denied for <moz-safe-about:blank> to get property Window.document from <>.

As requested, here's a dump of the environment variables:


ORBIT_SOCKETDIR=/tmp/orbit-robod
SSH_AGENT_PID=2445
TERM=xterm
SHELL=/bin/bash
XDG_SESSION_COOKIE=5aeb2a1f01ca599ee66b97e34bd70a02-1288080135.881821-1222710413
WINDOWID=46137348
OLDPWD=/home/robod
GNOME_KEYRING_CONTROL=/tmp/keyring-1WBaj8
GTK_MODULES=canberra-gtk-module:gail:atk-bridge
USER=robod
LS_COLORS=rs=0:di=01;34:ln=01;36:hl=44;37:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
SSH_AUTH_SOCK=/tmp/keyring-1WBaj8/ssh
DEFAULTS_PATH=/usr/share/gconf/gnome.default.path
SESSION_MANAGER=local/mihai:@/tmp/.ICE-unix/2411,unix/mihai:/tmp/.ICE-unix/2411
USERNAME=robod
XDG_CONFIG_DIRS=/etc/xdg/xdg-gnome:/etc/xdg
DESKTOP_SESSION=gnome
PATH=/home/robod/bin/mozilla-tools:/home/robod/bin:/home/robod/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
PWD=/home/robod/src/mozilla-mihai-devtools-work
GDM_KEYBOARD_LAYOUT=ro
LANG=fr_FR.utf8
GNOME_KEYRING_PID=2392
MANDATORY_PATH=/usr/share/gconf/gnome.mandatory.path
GDM_LANG=fr_FR.utf8
GDMSESSION=gnome
SPEECHD_PORT=7560
SHLVL=1
HOME=/home/robod
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
LESS= -R 
LOGNAME=robod
XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jvtuGFqnQB,guid=d594840802d823b1f861f9eb4cc68b05
LESSOPEN=| /usr/share/source-highlight/src-hilite-lesspipe.sh %s
DISPLAY=:0.0
LESSCLOSE=/usr/bin/lesspipe %s %s
XAUTHORITY=/var/run/gdm/auth-for-robod-OepEEU/database
COLORTERM=gnome-terminal
_=/usr/bin/env

This is Ubuntu 10.04 (amd64), using Gnome, all up-to-date.

This looks like it's related to bug 605470.

Comment 1

[Rob Campbell [:rc] (:robcee)]

possible dupe of bug 462238 ?

Comment 2

[David Dahl :ddahl]

WFM on changeset c133d3c084c0 32-bit ubuntu 10.04

Comment 3

[David Dahl :ddahl]

Also ran entire test suite, WFM. (again, 32 bit linux)

Comment 4

[Rob Campbell [:rc] (:robcee)]

I just ran it locally in an ubuntu 10.04 vm and passed all tests.

Mihai, can you paste your .mozconfig in here?

Comment 5

[Mihai Sucan [:msucan]]

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.

Comment 6

[Mihai Sucan [:msucan]]

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.

Comment 7

[Rob Campbell [:rc] (:robcee)]

wfm in OS X - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101031 Firefox/4.0b8pre

Comment 8

[Mihai Sucan [:msucan]]

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.

Comment 9

[Kevin Dangoor]

mass change: filter on PRIORITYSETTING

Comment 10

[Mihai Sucan [:msucan]]

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!

Comment 11

[alexander :surkov (:asurkov)]

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.

Comment 12

[Mihai Sucan [:msucan]]

(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.

Comment 13

[alexander :surkov (:asurkov)]

(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?

Comment 14

[David Dahl :ddahl]

Mihai: have you seen this problem lately?

Comment 15

[Mihai Sucan [:msucan]]

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.

Comment 16

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Changed component to "Disability Access."

Comment 17

[Nicolas Chevobbe [:nchevobbe]]

Test does not exist anymore