Improving XML error pages (YSOD)

[Matthew Wilson-4]

Hi all,

  I thought I might have a look at bug 418305 (Make Yellow-Screen-Of-
Death More Informative). My first effort was going to be to make the
error page look a bit more like the new network error pages.

  Currently the YSOD page is produced in nsXMLContentSink which
creates a page with a "<parsererror>" root element. This is relied on
by other code and extensions so I guess it should stay the same.

  I tried adding a processing instruction into the parsererror
document, transforming it into a error page with XSLT, but I got an
error saying that the stylesheet couldn't be loaded.

  Then I thought I might be able to use an nsIContentSniffer to detect
the "<parsererror>", but the content sniffer sees the original XML
page, not the error page.

  Any ideas on better ways to do this? I could just enhance
nsXMLContentSink to produce a more complex page, but it might be
better to leave that interface only for backwards-compatibility.

Matthew

_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Boris Zbarsky]

matthew@... wrote:
>   Currently the YSOD page is produced in nsXMLContentSink which
> creates a page with a "<parsererror>" root element. This is relied on
> by other code and extensions so I guess it should stay the same.

Perhaps...  I see no reason not to change this in a future release, for what
it's worth.

>   I tried adding a processing instruction into the parsererror
> document, transforming it into a error page with XSLT, but I got an
> error saying that the stylesheet couldn't be loaded.

XSLT can only be loaded same-origin.

>   Then I thought I might be able to use an nsIContentSniffer to detect
> the "<parsererror>"

nsIContentSniffer works on the original byte stream before anything gets
anywhere near the XML parser.

>   Any ideas on better ways to do this? I could just enhance
> nsXMLContentSink to produce a more complex page

You can do that, or you can use XBL (a la XML prettyprinting, but bound via a
stylesheet in this case) to make the page look different without changing the
actual DOM.

-Boris
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Matthew Wilson-4]

On Mar 23, 7:08 pm, Boris Zbarsky <bzbar...@...> wrote:
> matt...@... wrote:

...

>
> >   Any ideas on better ways to do this? I could just enhance
> > nsXMLContentSink to produce a more complex page
>
> You can do that, or you can use XBL (a la XML prettyprinting, but bound via a
> stylesheet in this case) to make the page look different without changing the
> actual DOM.

Thanks for the tip, the XBL route is looking promising.

Matthew
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Jonas Sicking-2]

matthew@... wrote:

> Hi all,
>
>   I thought I might have a look at bug 418305 (Make Yellow-Screen-Of-
> Death More Informative). My first effort was going to be to make the
> error page look a bit more like the new network error pages.
>
>   Currently the YSOD page is produced in nsXMLContentSink which
> creates a page with a "<parsererror>" root element. This is relied on
> by other code and extensions so I guess it should stay the same.
>
>   I tried adding a processing instruction into the parsererror
> document, transforming it into a error page with XSLT, but I got an
> error saying that the stylesheet couldn't be loaded.
>
>   Then I thought I might be able to use an nsIContentSniffer to detect
> the "<parsererror>", but the content sniffer sees the original XML
> page, not the error page.
>
>   Any ideas on better ways to do this? I could just enhance
> nsXMLContentSink to produce a more complex page, but it might be
> better to leave that interface only for backwards-compatibility.

FWIW I hate how we do these error pages. The <parsererror> stuff should
never be exposed to the web. We should be using null where possible and
empty documents where not.

So I don't think we should be aiming at backwards compat here. Instead
we should do a proper implementation that returns an empty document for
window.document and use whatever mechanism we're using for network
errors instead.

/ Jonas
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml