Opera Developer News

Acid3 test broken with this snapshot. This snapshot only scores 99/100.

Failed test - Test 80 failed: XML well-formedness error didn't stop script from executing

Originally posted by Swapnil99pro:

Failed test - Test 80 failed: XML well-formedness error didn't stop script from executing

Opera will probably have to have a default site preference for acidtests.org to turn this feature off. Or, that test will have to be removed from acid3 (some tests were recently removed already).

Bad news, people have to know there are sites badly written. Was better it there was a specific work around only for sites with the MIME malfunctioning in sniffing or, at least, a pop-up message to advise the user about the HTML reparsing of the page.

Ciao, Igor

Originally posted by burnout426:

Opera will probably have to have a default site preference for acidtests.org to turn this feature off. Or, that test will have to be removed from acid3 (some tests were recently removed already).

I'm curious how the other browsers that are less strict about XML parsing pass that part of the test.

I've got to say I never thought XML draconian error handling was a good idea (at least in a web context), but nevertheless my feelings about this change are mixed. It'll sure take some getting used to using the error console when dealing with XHTML.

Originally posted by Dillon:

I'm curious how the other browsers that are less strict about XML parsing pass that part of the test.

What other browsers are less strict about XML parsing? Firefox throws the most unfriendly error imaginable, Webkit renders up to the encounter of the error and IE gives a proper error (but of course not with XHTML). Opera's now the lenient outlier.

THANK YOU SOOO MUCH!

Originally posted by Frenzie:

What other browsers are less strict about XML parsing? Firefox throws the most unfriendly error imaginable, Webkit renders up to the encounter of the error and IE gives a proper error (but of course not with XHTML). Opera's now the lenient outlier.

Well Firefox, for example, doesn't take you to an error page when, say, visiting http://www.peiwei.com but then I haven't checked to see if they're only sending the xhtml header to Opera. Maybe I misunderstood but I thought this XML change was to automatically bypass that error page, an error page that I don't see in other browsers except in IE sometimes.

I think they are identifying Opera as a mobile browser only. When I masked as Firefox, all site is working fine

Arch!! finally!
We used to hard-code the MIME type in our asp.net applications!

Thanks!!

Originally posted by Dillon:

Well Firefox, for example, doesn't take you to an error page when, say, visiting http://www.peiwei.com but then I haven't checked to see if they're only sending the xhtml header to Opera. Maybe I misunderstood but I thought this XML change was to automatically bypass that error page, an error page that I don't see in other browsers except in IE sometimes.

I'm talking about pages where Firefox and Opera actually receive the same thing. My point is XML parsing is strictly — and draconically — defined, so all browsers do the same thing. Except Opera now, that is.

Press Ctrl+Alt+Shift+U if you really want to check the validity *after* you've produced your XML content and have sent it to the browser. But waiting for browsers to crap out isn't such a good strategy, why not make sure your production pipeline is XML-safe to begin with? Don't bother the end user with it...

Opera users got far more of these error pages than users of the other browsers, for reasons explained in this blog post.

And many sites will serve a javaphone-style page to Opera Mobile, which is why the devs added option to identify as Opera Desktop instead.

Originally posted by Rijk:

Press Ctrl+Alt+Shift+U if you really want to check the validity *after* you've produced your XML content and have sent it to the browser. But waiting for browsers to crap out isn't such a good strategy, why not make sure your production pipeline is XML-safe to begin with? Don't bother the end user with it...

I've always considered Opera's strategy with the reparse as HTML option superior to especially what Firefox does; I'm merely pointing out that other browsers aren't more lenient.

Originally posted by burnout426:

Or, that test will have to be removed from acid3 (some tests were recently removed already).

Oh yeah, now I understand-

Test 80 failed: XML well-formedness error didn't stop script from executing

The above test means that XML code with mistakes should trigger "XML parsing failed" and not to execute the script. But due to Opera changing this behavior this XML code with mistakes is re-parsed as HTML and the test script on Acid3 can run. So passing this test isn't necessary, right? But I have some questions-

1. Does this affect a website with fully correct XML code?
2. Is this change a right decision in regards to other browsers?

Originally posted by Swapnil99pro:

1. Does this affect a website with fully correct XML code?

No. Not at all. What this does is reparse markup as HTML that should have been sent as text/html in the first place. Because of browser sniffing, Opera often gets pages like this while other browsers do not.

Opera already allowed you to do the reparse. Now it's just automatic, which makes a lot of sense since everyone that wanted the page to work clicked the reparse link anyway.

The only problem with this is that when you encounter real xml markup that was meant to be sent as application/xml or application/xhtml+... but has an error, Opera will no longer show you an error message telling you something is wrong, which is useful when authoring an xml file and useful for error detection so you can report the problem to the site. Also, a real xhtml page with an error that uses scripting that is reparsed as HTML will load, but might not behave properly, which can give false expectations.

Browser vendors have argued about the pros and cons of this for years. We'll just have to see if this takes off.

Originally posted by Rijk:

Don't bother the end user with it...

It is the XHTML standard.
An error page with a countdown of some second and then an automatic reload reparsing as HTML can be a better and correct solution.

Ciao, Igor

@Igor: the XML standard says that we should give an error (we still do, in the error console) and stop parsing the XML. It doesn't say we can't then reparse those bytes as text/html - Opera is not continuing the XML parsing, that would be a violation indeed.

Why not build a human and developer friendly error page:

"This page uses broken XML but we will try to reparse it as HTML with error correction in [5s countdown] second(s) to retrieve all content possible.

If you want to see the full error message instead: [Click here]"

Originally posted by QuHno:

Why not build a human and developer friendly error page:

"This page uses broken XML but we will try to reparse it as HTML with error correction in [5s countdown] second(s) to retrieve all content possible.

If you want to see the full error message instead: [Click here]"

This can be good and clear for all, as i suggested too.

Originally posted by Rijk:

@Igor: the XML standard says that we should give an error (we still do, in the error console) and stop parsing the XML

But the error have to be seen, no one can see it if he have not asked to see the error console and it is not istructive to repharse automatically because people have to know the bad work of some webmasters instead of telling that Opera is not well working and a correctly XHTML made website can work in bad way if reparsed.
So reparse have to be clearly declared (can be also a pop-up message or at the top of the page, like the save password bar).

Ciao, Igor

Originally posted by QuHno:

Why not build a human and developer friendly error page:

"This page uses broken XML but we will try to reparse it as HTML with error correction in [5s countdown] second(s) to retrieve all content possible.

If you want to see the full error message instead: [Click here]"

If you go that route I think it'd be better to show it as a non-interrupting notification (akin to the save password dialog).

Or one of those.

(Sorry for the x-post double-rant, but I think it is important)

Originally posted by QuHno:

Why not build a human and developer friendly error page:

"This page uses broken XML but we will try to reparse it as HTML with error correction in [5s countdown] second(s) to retrieve all content possible.

If you want to see the full error message instead: [Click here]"

That's the way Opera did in the past. Ok .. without a countdown.
That couldn't be the solution. Most of the Internet users aren't geeks like us. And when a site doesn't load, it's a browser problem ... other browsers obviously hasn't this problem ... so a normal user changes.
I know it's a dilemma, but I think it's the best solution.
Could there any better for 'normal' users?

No, in the past Opera said that the XML parsing failed because of something that is called "Syntax Error", linked to a "cryptic, geeky and techy" reference that no "normal" user can understand or wants to understand and showed some "cryptic" code below that.

It looked a little bit like a blue screen of death but in gray ant with a cut off big red O in the top right corner, the same as other internal pages, so it must be an internal parser mistake because there was no hint, that it was the page that caused it and not the parser that broke.

[retry][abort][ok]</windowsjoke>

The changed message bears a different and clear non-tech message:

The page, not this browser is broken. We will do our best to repair it in some seconds. This is just to inform you, no need to worry, all will be good in some seconds (hopefully).

... with an option to get the tech version for all who are interested in it. IMHO great psychological difference.


Please read the above with the eyes of a normal user - so to say a user who will never look at this blog post or these comments

I really like Opera previous behavior of informing the user. I think the error page has not been the best (read: user friendliest) solution, therefore improvements are welcome. But those error shouldn't be just logged away.

Consider this: Would we have actually identified those non well-formed sites? Honestly, I don't think so. Probably the ASP bug wouldn't have been fixed either.

Originally posted by QuHno:

The page, not this browser is broken. We will do our best to repair it in some seconds. This is just to inform you, no need to worry, all will be good in some seconds (hopefully).

I'm also a software developer ... no one read such a message. There's an error, that other browsers haven't ... that's it.
I understand your intention ... but the people don't fit to it.
Change the people ... or change the browser.
I appreciate that Opera takes the easier way ...

Originally posted by schwiebie:

I'm also a software developer ... no one read such a message. There's an error, that other browsers haven't ... that's it.

... and it recovers automatically, which other browsers obviously can't - at least Fx and IE didn't the last time I saw such an "XML parsing failed" message.

Advertisement in big, neon shining letters:
Opera is the first (and only) browser that can automatically recover from XML parsing errors in just 5s!

Originally posted by QuHno:

Advertisement in big, neon shining letters:
Opera is the first (and only) browser that can automatically recover from XML parsing errors in just 5s!

Then someone else will do it in 4 seconds, or instantly

The problem for the users is gone if all do it ...

... after all are doing it we just need an option for those people that are looking for bugs so that they don't need to have the error console constantly popping up, just a tiny option in opera:config like:

Show XML parsing errors in tabs [X]

... and everybody is happy.

Hm, could we just get this option before all others do it?

Originally posted by schwiebie:

I'm also a software developer ... no one read such a message. There's an error, that other browsers haven't ... that's it.

But the error is in the MIME sent to the browser, not in the browser so, why not to crate a workaround for that sites using something like the browser.js. The other browsers will continue to show the error page for erroneous pages when the MIME will be "application/xhtml+xml" and Opera not.

Maybe pop a bar that says "This page was repaired. If it still looks wrong, click [here] to let us know.

A good placement for the seldom-used "report a site problem" help option.

in 11.5 there is "parse as html", I dont get why you want to change this. With this was it enough

Originally posted by hellspork:

Maybe pop a bar that says "This page was repaired. If it still looks wrong, click [here] to let us know.

+1 for all pages that were repaired, vanishing after some seconds just like it is now with the "Wand Store Toolbar"

additionally a "I don't care" button, that hides it forever for that page or globally for all who don't care and a "XML parsing failed, click [here] to view the error page" if it was an XML parsing error.

This way everyone is happy:
Those who don't care never have to see it again, all others can see if a page was corrected and can report still occurring errors with one click.


Some more ideas:
For the error infobar I could even imagine something like: "You can mark the problematic area in the page and write something about the nature of the problem." to make the work for the poor guys who have to write the browser.js easier.

If the XML is b0rked, wouldn't it be better to test with a second request with a masked UA (saying in the comments section that this is done because of the WAI), if there is such a version for i.e. Firefox (or any other arbitrary header) and if yes retrieve that page?
That could be better sometimes than re-parsing a broken page, which might fail anyway if not only the MIME-type, but the content too was changed due to wrong browser sniffing.

Originally posted by QuHno:

If the XML is b0rked, wouldn't it be better to test with a second request with a masked UA (saying in the comments section that this is done because of the WAI), if there is such a version for i.e. Firefox (or any other arbitrary header) and if yes retrieve that page?
That could be better sometimes than re-parsing a broken page, which might fail anyway if not only the MIME-type, but the content too was changed due to wrong browser sniffing.

Agreed.

Originally posted by igorditerni:

Originally posted by schwiebie:

I'm also a software developer ... no one read such a message. There's an error, that other browsers haven't ... that's it.

But the error is in the MIME sent to the browser, not in the browser so, why not to crate a workaround for that sites using something like the browser.js. The other browsers will continue to show the error page for erroneous pages when the MIME will be "application/xhtml+xml" and Opera not.

Because there's too much of this, so the browser.js/override.ini solution doesn't scale.

Originally posted by zoquete:

in 11.5 there is "parse as html", I don't get why you want to change this. With this was it enough

Because users blame the browser when pages break, especially when it seems to work fine on other browsers.

Originally posted by Rijk:

Because users blame the browser when pages break, especially when it seems to work fine on other browsers.

sorry, tell me in what other browsers aren't xml-paring errors displayed. Thanks a lot

Originally posted by zoquete:

tell me in what other browsers aren't xml-paring errors displayed.

No there aren't any browsers where XML-parsing errors are not displayed except Opera. But Mr. Rijk is not talking about displaying XML parsing errors displaying, he is talking about this -

Websites give XML/XHTML content to Opera and HTML content to other browsers. Very minor HTML coding mistakes are handled by these other browsers and they don't need to get to into the XML matter. Now Opera who does not get HTML code has to parse the XML code only. Unlike HTML, even minor mistakes in XML code trigger "XML parsing failed". Now average users think that the site is working in other browsers and not Opera, because they don't know that Opera is rendering XML code while other browsers are rendering HTML. So automatic reparsing of broken XML code as HTML was introduced just for the normal users of Opera.

Originally posted by Swapnil99pro:

So automatic reparsing of broken XML code as HTML was introduced just for the normal users of Opera.

Which makes perfect sense as it's often just the case that the server is telling Opera the HTML markup is XML when it's not. Parsing it as HTML (as originally intended by the author that made a browser-sniffing mistake either directly or indirectly) is the right thing to do.

If there's an error, it might be possible to detect that the markup looks like HTML and only do the reparsing in that case and still show an error in other cases, but that could be difficult to get the detection right and robust. The way Opera does it is just easier to code.

Originally posted by burnout426:

it might be possible to detect that the markup looks like HTML and only do the reparsing in that case

You'll know the difference between application/xhtml+xml and application/xml, right? It's all in the name Opera receives xhtml+xml (thus HTML "packaged" in an XML correct form) while other browsers receive text/html.
If the above comment from Swapnil Rustagi about Acid failing in an XML test is right (not running next so can't test, and not in the mood to read the acid test), it's Opera's fault, no matter how you look at it. If the content type is application/xml Opera shouldn't be reading it as HTML if the markup is faulty (because it's just plain XML, and not HTML packaged as XML). If the content type is application/xhtml+xml, I still think Opera should give some kind of error (and I agree the current/previous message is not user friendly), but now they decided to just ignore the fault (who looks at the error console anyway?) and reparse it as HTML.

That's actually a pretty good idea.

Originally posted by Robert90:

You'll know the difference between application/xhtml+xml and application/xml, right? It's all in the name Opera receives xhtml+xml (thus HTML "packaged" in an XML correct form) while other browsers receive text/html.

I'm specifically talking about a page like this:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title></title>
    </head>
    <body>
        <p><input></p>
    </body>
</html>

that ends up being served to Opera as text/xml, application/xml or application/xhtml+xml. In the case of application/xhtml+xml, you can pretty much assume that it's some kind of html content (although the assumption could still be wrong) and reparse as HTML if there's an error. But, with application/xml and text/xml, you could have a real XML file that just happens to have an html element (the document element in this case). But, without xmlns="https://www.w3.org/1999/xhtml" somewhere (it shouldn't be there for content meant to be served as text/html unless you're using a polyglot document), you're making a much bigger assumption based on just the document element having a name of "html". So, if you want to be more confident that it's really HTML content, you might want to also look at other things in the document (like the presence head, body, title, meta) before you reparse. But, if there's a parse error really early, there's not going to be much to look at (unless Opera does a string search on the source). So, yeh, it's possible to limit the reparsing to pages that look like HTML. But, if I have a real xml file like:

<html>
    <zipzambam></zipzambat>
</html>

, I'd still want Opera to show that there's a parsing error. Given that, it's just easier to have reparsing for all xml files with an option to turn it off when developing/testing. But, maybe everyone is fine with assuming that XML markup (like that even) is HTML where Opera should reparse on error. That would allow Opera to limit the reparsing to things that look like HTML.

Originally posted by burnout426:

Which makes perfect sense as it's often just the case that the server is telling Opera the HTML markup is XML when it's not. Parsing it as HTML (as originally intended by the author that made a browser-sniffing mistake either directly or indirectly) is the right thing to do.

I have a test XHTML page, in one of my websites wrote in really valid XHTML, that contains a simple stupid error with the purpose to show the error page to teach browsing people the right way a browser have to show it and i have every time suggested to use Opera for the best result... I will have to delete the suggestion if the page will be displayed in Opera 12 (like now is displayed with this version).

Ciao, Igor

A samll hint in the address bar would be enough, something like a small XML in a square, just like the icon for RSS feeds. If it is visible, all "knowing" people would know, that there is something smelling rotten and with a click on it the error console could open to hopefully show the same detailed error message like the former error page.

That would be unobtrusive IMHO.

I believe if I think long enough I can come up with several other ideas for showing in an unobtrusive way that the page was re-parsed to ease the live of people who want to know whats wrong.

@QuHno: But why do you want to know, and also show it to everyone? Just like we don't show an indicator when a page is invalid HTML... I wouldn't mind a switch in opera:config for testing purposes for those who need it, but I really like the idea of not setting up all the millions of Opera users as guinea pigs

Note: I'm not involved in testing or developing this feature!

One example:
Imagine an extension or some UserJS that trusts in a certain structure of a webpage. Now imagine a server, that sends Opera a broken X(HT)ML page. Opera silently re-parses it and you know what the JS will see after an error correction. Sometimes that has not much to do with the structure intended by the author of the page.

The extension fails. The user has no hint why and writes a bug report to the extension or userJS author. If there were a hint, the user at least would have a chance to recognice, that there was something else that broke.

Off course X(HT)ML pages should be valid - but several of these pages are compiled by CMS and you know that there is at least one coding error in each 1000 lines of code and error correction in Opera is (still) some kind of sophisticated guesswork (yes, I know that will change in future when the HTML5 parser is up and running - thanks to the well defined error correction that is part of the spec)

BTW: Re-parsing on speculation that broken X(HT)ML is HTML content with the wrong MIME Type is like using the millions of users as guinea pigs too

edit:
PS: Another case happened to me today - some syndicated content not under my direct control suddenly had an error. The page itself was valid XHTML strict before (even Schema validated). Opera 12 in its clean-install default settings silently switched to HTML and failed miserably in displaying the page. It would have been better to get the error or at least a hint why it failed. There was nothing, in the default install I even had to open the error console manually.

My very personal opinion:
AFAIK the spec says that an error must be shown. An error message I can't see in the default settings without my active interference is IMHO not shown.
Is some half hidden 16*16px indicator really too much? Would it really annoy millions of Opera users?
If not: Can we have it? I think it would make several thousands of developers happy

@Rijk: Perhaps this idea can be transformed into a useful feature: Image the indicator, telling you that XML parsing failed, combined with the information that Opera considers the page as invalid (X)HTML? It would be unobtrusive and informative - turning it on via a preferences / config switch sounds good.

Additionally, I have to go along with Michael A. Puls II, It has to be ensured that non-well-formed 'ordinary' XML does not accidentally parsed as HTML.

What I've been wondering of since reading this article. When XML parsing fails for an application/xhtml+xml content type, why don't you sent a HEAD request with a Firefox or IE user agent string? When that one returns a content type of text/html you can be damn sure it's an HTML file and a server configuration fault. The result of this HEAD request can then be saved/remembered during the browsing session as being "a faulty server configuration" and you don't have to check it again (and HEAD is only meant for GET requests, so for a POST request as follow up on the GET it would also be impossible to send a HEAD request, besides of course the consequences of multiple posts with the same data)

+1
Robert Maijers suggestion sounds pretty smart. Dear Developers, what do you think about that strategy?