Feedview should hook into gecko next to XML prettyprint




13 years ago
8 years ago


(Reporter: Axel Hecht, Unassigned)



Firefox Tracking Flags

(Not tracked)




13 years ago
Feedview currently observes each window load, and for unstyled XML, it kicks in
after Gecko has done the XSLT transform for XML prettyprint.

This is both a perf problem and a problem with the feed XSLT not working on the 
original DOM doc. I'm not confident the XML pretty printing result as good as 
we can for scripting.

Exposing a general hook for unstyled XML would also enable the reuse of that 
approach for other XML formats, read docbook. See bug 194351, bug 109684.

One suggestion is to use the observer service for this.


13 years ago
Blocks: 302121
Some sort of observer sounds like a great idea. We would need to have some sort
of priority mechanism since we want feedview to take priority over xml-prettyprint.

We would also have to expose bit of information about the doc to the observer
that the observer can use to choose wheather to apply its style or not. For
example xml-prettyprint does not want to style documents that contain XHTML
elements or stylesheets, whereas feedview doesn't care about either of those.

Comment 2

13 years ago
I was thinking of using the XML document as subject for the hook, and to use 
specific nsresults to indicate whether a observer wants to transform this doc.

And if no observer yells, feed it to pretty printer. We could of course QI to
a richer interface right away, which could return a priority number, for example.
Actually, i think you might be right that the normal observer interface is
enough. We only really need 2 levels of priority; everything else and
xml-prettyprint. Since stuff in the "everything else" group should never
overlap. I.e. a document can't be both a feed and a docbook.

So your suggestion should work fine.


13 years ago
Component: General → RSS Discovery and Preview
Version: 1.0 Branch → Trunk
> I.e. a document can't be both a feed and a docbook.

What about mixed-namespace documents, couldn't those cause some overlap?
I don't think so. XSLT is able to copy parts of the document thorough,
namespaces and all, then we'd normal layout rules to show that.

Comment 6

12 years ago
In terms of XSLT, yes, they could.
For feedview, this is void, as they don't really nest XML, but encode HTML 
content. Docbook seems pretty self-contained, though a docbook stylesheet should
probably have some guards to forward other namespaces, to make mathml work, for 
As soon as we support multiple XSLT stylesheets per processor, we could glue
those together smoothely (with a default document stylesheet, that is).
> For feedview, this is void, as they don't really nest XML, but encode HTML 
> content.

Be sure not to build that assumption into anything: Atom's content element can
have any XML as children: <content type="application/foo+xml"><blah
xmlns="...></blah></content> is perfectly valid Atom. You won't find docbook
because of its namespace issues, but anything else, most certainly XHTML, you may.
*** Bug 305087 has been marked as a duplicate of this bug. ***
Moving to Core:XML in case you still want this for other uses: Son of Feedview is going in even earlier in bug 324985.
Assignee: nobody → xml
No longer blocks: 302121
Component: RSS Discovery and Preview → XML
Product: Firefox → Core
QA Contact: general → ashshbhatt
Assignee: xml → nobody
QA Contact: ashshbhatt → xml
You need to log in before you can comment on or make changes to this bug.