Closed Bug 936301 Opened 11 years ago Closed 11 years ago

[B2G] cannot switch to an 'about:neterror' frame

Categories

(Remote Protocol :: Marionette, defect)

Product:
Remote Protocol
Component:
Marionette
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 937659

People

(Reporter: mikehenrty, Unassigned)

Details

Currently, if we attempt to switch to a frame that is in an 'about:neterror' state (for instance, by setting a frame url to 'http://my.bogus.url/' and then switching to it), marionette throws this error:

"UnknownError: (13) Error loading page"

Perhaps this is happening here: http://hg.mozilla.org/mozilla-central/file/4334336fae4d/testing/marionette/marionette-listener.js#l1205

In any case, in B2G we have a fancy about:neterror page, and we need the ability to test certain functionality therein. Is there a way we can work around this error, or can we allow switching to these frames in B2G?
Malini, any ideas about this one?
(In reply to Jonathan Griffin (:jgriffin) from comment #1)
> Malini, any ideas about this one?
Flags: needinfo?(mdas)
(In reply to Michael Henretty [:mhenretty] from comment #0)
> Currently, if we attempt to switch to a frame that is in an 'about:neterror'
> state (for instance, by setting a frame url to 'http://my.bogus.url/' and
> then switching to it), marionette throws this error:
> 
> "UnknownError: (13) Error loading page"
> 
> Perhaps this is happening here:
> http://hg.mozilla.org/mozilla-central/file/4334336fae4d/testing/marionette/
> marionette-listener.js#l1205
> 
> In any case, in B2G we have a fancy about:neterror page, and we need the
> ability to test certain functionality therein. Is there a way we can work
> around this error, or can we allow switching to these frames in B2G?

Marionette's a webdriver implementation, and we're following the https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#page-load-strategies 'normal' guidelines for loading a page. This means that if the document.readyState doesn't become 'complete' within some time period, we return with an error message. All about:*error pages remain in the 'interactive' readyState and never go to 'complete', so we return with an error, since this is not considered to be a normal page to navigate to. On top of this, we have a regex that looks for about:*error pages, since, for the typical user, you expect to treat this webpage navigation as an 'error' since you get it when you mean to navigate to a valid page, but that page is not what you expected. We may be able to remove this part, since I don't see any mention of this behaviour in WebDriver.

This being said, you're still in the context of the webpage if you get that error. You don't need to switch into any frames. So if I do:

marionette.navigate('http://my.bogus.url/') #this throws an error

It throws the error, but if you look at the page source, you know you're in the expected page:
print marionette.page_source

returns:

u'<!DOCTYPE html>\n<html xmlns="http://www.w3.org/1999/xhtml"><head>\n    <meta charset="utf-8" />\n    <meta content="width=device-width, user-scalable=no" name="viewport" />\n  </head>\n  <body style="background-color: blue; color: white; position: fixed; height: 100%; width: 100%;">\n    <h2>Something bad happened, but don\'t worry a new better error page is coming soon..</h2>\n    <h3>see bug 882186</h3>\n  \n\n</body></html>'

So what you can do is:

try:
  marionette.navigate('some broken url')
except MarionetteException:
  pass
*your code here*

Alternatively, you can wait until we implement pageLoadingStrategy support, so you can then choose how we load pages, so we will return 'interactive' pages as valid pages, and you won't need to catch an error. In this case, the current spec says you must choose your strategy when starting a new session, but perhaps having a command to change the strategy on the fly (or an additional parameter to navigate) might be more useful, so you can opt in to strategies on the fly. This is being discussed here: Bug 937659
Flags: needinfo?(mdas)
Thank you for the information Malini! For the time being, catching the error in the Marionette client works just fine. Marking this as a duplicate of bug 937659, as that will give us exactly what we need in the long run.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
No longer blocks: 882186
No longer depends on: 940084
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.