554416 - Cannot access tree.view by id when running tests with Mozmill in Firefox 3.5.x

Status: RESOLVED WONTFIX

(Testing Graveyard :: Mozmill, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Whatever tree we want to access with Mozmill in Firefox 3.5.x it doesn't work. tree.view is always not accessible. See a test case on bug 545021.

There is no problem with Firefox 3.6 and up. So I wonder what is wrong by accessing a view that way:

var list = document.getElementById("cookiesList");
var view = list.view;

Result: View is not defined

This is one major issue for us because it blocks a couple of Mozmill tests. I will add them to the dependency list.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The test I meant is attachment 433943 [details].

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is definitely a regression in Mozmill 1.3. It works fine with Mozmill 1.2.1.

Possible candidates:
https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=verified-mozmill-1.2.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Eventually not a Mozmill regression. This one is kinda hairy.

Comment 4

[Martijn Wargers (dead)]

When I do    controller.window.alert(controller.window.location);
I get back: chrome://browser/content/browser.xul
This is the same in Firefox3.5 and Firefox3.6.

This line of code is returning the treeview in Firefox3.4 and Firefox3.6:
controller.window.alert(controller.tabs.activeTabWindow.document.getElementById('tabList').view);

I guess the elementslib.ID function is doing some stuff that doesn't work properly in Firefox3.5, but works fine in Firefox3.6.
My guess it has something to do with security related stuff. The code in the elementslib.ID function seems to crawl through all the frames inside the mentioned window, looking for the element that has that particular ID.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #4)
> I guess the elementslib.ID function is doing some stuff that doesn't work
> properly in Firefox3.5, but works fine in Firefox3.6.
> My guess it has something to do with security related stuff. The code in the
> elementslib.ID function seems to crawl through all the frames inside the
> mentioned window, looking for the element that has that particular ID.

Thanks Martijn! Lets ask Blake if he has an idea which patch could have fixed that in Firefox 3.6 but hasn't been backported to Firefox 3.5.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As Martijn pointed out on IRC and which was verified by running the appropriate builds to test this is related to bug 480205. Looks like it will not be fixed for Firefox 3.5. I will try to use the workaround from above.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I will leave this bug open until we know if the patch on bug 480205 will be landed on 1.9.1 or not.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The view will be accessible when we unwrap the XPCNativeWrapper. Given that we depend on bug 573185.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Firefox 3.5 is no longer supported. Closing this bug.