Closed Bug 521762 Opened 15 years ago Closed 12 years ago

MozMillController#open fails in Firefox if the Navigation Toolbar is hidden

Categories

(Testing Graveyard :: Mozmill, defect)

Product:
Testing Graveyard
Component:
Mozmill
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dougkearns, Assigned: whimboo)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: 1.2.1

MozMillController#open calls window.openLocation in Firefox.  Unlike window.ShowAndSelectContentsOfURLBar in SeaMonkey this does not make a hidden Navigation Toolbar visible it opens the "Open Web Location" dialog instead.

As a result, the requested location is not opened and the dialog is left open awaiting input.

Reproducible: Always
OS: Windows XP → All
Hardware: x86 → All
The problem is that in such a situation a modal dialog is displayed which cannot be handled by Mozmill itself. We have a function inside the shared modules for our firefox tests but it hasn't been migrated into Mozmill yet.

Mikeal and Clint, do we really have to use the way via the location bar? I would propose to use a function from gBrowser to open the web page instead of using the location bar itself. Tests which cover the location bar interaction will definitely use their own sequence so it's not needed for controller.open.
(In reply to comment #1)
> Mikeal and Clint, do we really have to use the way via the location bar? I
> would propose to use a function from gBrowser to open the web page instead of
> using the location bar itself. Tests which cover the location bar interaction
> will definitely use their own sequence so it's not needed for controller.open.

I agree with Henrik here, I think that there is more than one way a user can open a new page, one is typing into the url bar, but you can also copy and paste into the url bar, follow a link, etc. so it doesn't make sense to try to mimic this one path to opening a new page. I would argue that typing and selecting from the autocomplete is the most common way anyways, and that's not what you do in 'open'.

It's also a bit fragile and 'open' isn't working for me right now.
The expectation is that people will regularly want to open pages for testing, so abstracting it makes it much simpler to write the tests.

In most cases, the test author only needs to open the page as a prerequisite for other testing so making assumptions about the method by which they want to open the page is fine since it's not the focus of the test. If we want to create a series of tests for different methods of opening pages then we can explicitly do that and just ignore this API.

If it's not working, that's an issue that needs to be fixed. And the current way of doing open can change if we know of a more reliable/faster way of doing it since, as I just stated, the intention of the API is to abstract a common operation not necessarily to test a particular strategy for opening pages.
I have tested a bit around this problem and have noticed that not only Mozmill has problems in opening an URL when the navigation bar is hidden. Even the loadURI function of the webnavigation object fails to load the specified URL. The open location dialog pops-up and is waiting for input.

Dao, is this really an intended behavior? I wonder about because I cannot find an existing bug for that issue. Do we really rely that strong on the visibility of the location bar?
Status: UNCONFIRMED → NEW
Ever confirmed: true
gBrowser.loadURI("about:config") wfm if the location bar is hidden.
That's interesting. When I use the following code in a test it works fine too:

controller.window.gBrowser.loadURI("http://www.google.de");

But when I change the Mozmill code to "this.window.gBrowser.loadURI(url);" it fails when running the test via the IDE. But it is fine when running it from the command line.

It sounds like a similar problem like bug 503480. Lets see if the patch on that bug will help us here.
Depends on: 503480
this.window.browser.loadURI(url) works great for me even from the IDE, as long as you take out the this.window.openLocation(). How does this fail for you Henrik? what happens?
Proposed fix:
http://github.com/whimboo/mozmill/commit/457de32f8633ec6658b43995bb2a9bca9d33a108
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
works great on Firefox and Seamonkey(2.0) for me, thanks Henrik!
Thanks for testing Heather. Meanwhile this temporary solution has been merged into the master. For a final solution we have to handle the modal dialog which gets opened. Therefor we need bug 525187 which will integrate the modal dialog module into Mozmill. Until then I'll leave this bug open.
Depends on: 525187
What modal dialog gets opened for you?
We want to simulate user actions. loadURI circumvents that. When the location bar is not visible the user will get the modal dialog. And we shouldn't use a way other than that.
We do want to simulate user interactions but, as stated before, this particular API is more about convenience than it is about user simulation methodology.

The only concerning thing for me is that if a modal dialog is opened it might cause something weird or unexpected to get caught and we lose control in the main thread.
I don't get a modal dialog when I call controller.open() if the location bar is hidden (at least on Firefox 3.5 on Linux), and it would really be a bug if that were the case. Also, I thought the point was to smooth over this action for tests that aren't testing the url bar? not to simulate it?
IMHO controller.open() shouldn't be short hand for "load a URI in the urlbar", I think that it should, for example, work in a small browser window that has the urlbar hidden.
Dao, I would need you help. We have a regression in one of our tests where we test the I'm feeling lucky search on Google. Our text which we want to open is "oau45rtdgsh34nf". Before we made the change on that bug it was working fine but now it is broken because it want to open www.oau45rtdgsh34nf.com.

Is that the intended behavior or do we have a bug here? In both cases it looks like we have to revert the last patch.
I think you want to use window.loadURI(url, null, null, true /* allow third party fixup */);
it seems like for that kind of test you'd want to use controller.type instead of controller.open, since it's testing the url bar's functionality.
Yeah, that make sense. I will file a follow-up so we can fix the test.
So my proposed fix has been landed a while ago even for Mozmill 1.x. Closing as fixed.

https://github.com/mozautomation/mozmill/commit/457de32f8633ec6658b43995bb2a9bca9d33a108
Severity: major → normal
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.