[fauigerzigerk]

Difficult edge cases are never a good reason not to support the 99.9% case.

Also, phantomjs has access to all the information you want and the WebDriver API already has a capabilities negotiation facility.

[Edit] Don't forget that the original URL is the only one supplied by the client of the API. It may be incorrect for very different reasons than all the other resources included by the page itself. That's why it is justified to treat it as a special case.

[nirvdrum]

These aren't edge cases. They're asked about constantly. Most people are using Selenium because they care about everything on the page. Otherwise, your stdlib HTTP client would be sufficient.

That aside, if PhantomJS already has the info, you can always fetch it with executeScript.

If you do feel that strongly about the status code part though, I'd urge you to comment on the public draft of the W3C spec: http://www.w3.org/TR/webdriver/

[cstejerean]

From the point of view of simulating actual users, the fact that some random third-party resource on the page failed to load is not particularly relevant. That happens all the time as I browse around the web, and I never have to care about it as long as the site continues to function. So it very much is an edge case compared to the page itself failing to load.

[nirvdrum]

A JavaScript file failing to load will bork most pages. A CSS file failing to load or a key image will cause most people to quit. And an Ajax request failing in a single-page app will render it useless.

But, my point of view is from actual Selenium users. This is framed by providing support on the IRC channel, on the mailing lists, triaging the issue tracker, and by interacting with people at SeleniumConf and the local Boston meetup. It's not some fringe use case and I'm not arguing the point for the sake of arguing it. The original supposition that it's an edge case is not accurate. And sure, the web breaks. That's why people using Selenium would like a way to catch that. And that's a big part of why the BrowserMob Proxy project exists.

[encoderer]

"A JavaScript file failing to load will bork most pages. A CSS file failing to load or a key image will cause most people to quit."

Wha?

Sure, if, say, "app.js" fails to load, you have a problem.

But an analytics script?

A 3rd party ad script (which is what the GP gave as an example)?

These things can and do fail all the time.

[fauigerzigerk]

I believe you can't use execute because any JavaScript you supply runs inside the page. You don't have access to the phantomjs specific callbacks you need to intercept http traffic.

[nirvdrum]

That's unfortunate. I don't work on PhantomJS, but I can try to track down someone on the team and see if there's a way to attach a handle to window or something.

[nirvdrum]

To follow up to your edit, that may be true in one case. But it's perfectly reasonable to navigate via clicking, anything in the navigate API, JS actions, meta refreshes, and so on. Even in that one case, most people would expect redirects to be followed and basic auth protected pages to submit. Again, all tractable problems, but ones that are likely better handled by an interstitial layer where you can see the entire chain of requests & responses.

[fauigerzigerk]

Browsers do see the entire chain of requests and responses. All of it. Some browsers make that information available externally. I just don't see why a browser remote control solution like Selenium shouldn't pass on as much of this information as possible.