Closed Bug 64945 (xmlview) Opened 24 years ago Closed 22 years ago

Better Default layout for "vanilla" XML documents

Categories

(Core :: XML, enhancement, P2)

Product:
Core
Component:
XML
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.2beta

People

(Reporter: hans_k_97, Assigned: sicking)

References

(
URL
)

Details

(Whiteboard: [Hixie-P4][ADT3] see comment 113)

Attachments

(3 files, 20 obsolete files)

Sample XML file, use for testing
211 bytes, text/xml
Details
stage three! v2.2
39.92 KB, patch
sicking
: review+
sicking
: superreview+
asa
: approval+
Details | Diff | Splinter Review
RTL XML testcase
1.92 KB, text/xml
Details 
When looking at an XML document that doesn't have a stylesheet, the data output
needs to be more readable than simply displaying a space-separated list of the
available data elements.
I spend a lot of time looking at industrial XML and the (unfortunately
IE-centric) feature of being able to look at the entire document (including
tags) by default, with the ability to click and expand or close tags, etc.
without "view source" is very useful.  However, I don't think this is
necessarily correct behavior- but a similarly readable option would be invaluable.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Default layout for "vanilla" XML documents is unreadable → [RFE] Better Default layout for "vanilla" XML documents
Targeting for mozilla0.9.1
Target Milestone: --- → mozilla0.9.1
For a real world example compare ie to moz rendering
http://p.moreover.com/cgi-local/page?index_xml+xml

Because of the precedent set by IE we should show XML without stylesheet in a
similar way as IE. There should be a pref that controls the behaviour, so you
can turn the IEism off if you want (for example I usually would, because it
makes testing easier as you do not need to write a stylesheet every time).
OS: Windows 98 → All
Priority: -- → P3
Hardware: PC → All
Ok. If we implement this we have to be careful to avoid doing it for any
document that matches any of the following conditions:

   Has an <?xml-stylesheet?> PI
   Has XHTML anywhere in the document (including attributes)
   Has XUL anywhere in the document (including attributes)
   Has an HTTP Link header
   Has an XLink anywhere in the document
   Was created by script
   Is modified by script
   Contains an element or pseudo-element that has style applied to it by any
      rule in ua.css or related stylesheets (e.g., MathML or XBL elements)

Even then, we might have missed some cases where the best behaviour is to not
use the IE tree stuff. I can understand that web developers may wish to enable
a view source mode by default for XML documents -- but I do not see why end 
users (the majority of our users) would want to view the source of XML 
documents. If they come across an XML document on the web, it's a bug as far as
they are concerned -- the author should have used either a known language such
as XHTML or MathML or as a last resort should have provided a stylesheet.

If web authors want this then they can just go to "View Source".

In the unfortunate case where we _do_ implement this, then it is important in my
opinion to use the same layout as the View Source window. If we have two 
different view source mechanisms we would be both wasting resources and 
confusing users.

cc'ing mpt for UI advice.
Keywords: qawanted
Whiteboard: (py8ieh: test cases required)
I made a sample XML file that can be used to test the features - it also
shows what needs to be handled.

I made a first pass at a CSS stylesheet that could be used to achieve this.

I am thinking that we might want to attach a default script for these documents
as well, more on below...

Even though all of this must be controllable from prefs, these things should
probably be turned off if one of the following is true:

- the document contains an xml-stylesheet PI
- the document contains elements from namespaces we support and that get styles
  applied to them automatically (XHTML, XLink, SVG, MathML)
- there is a stylesheet attached to the document by some other means (HTTP
  headers)
- it is arguable that we might want to remove the defaults if some process
  later applies styles and/or scripts to the document

First time the user opens a plain XML document s/he should be presented with a
dialog box that asks whether s/he would like to enable the default XML
stylesheet or not, and whether the user would like to save the decision so we
will not ask it again (it should be in advanced preferences as well).

The prefs I am thinking about here would be:

// Style on/off: true or false, default true
pref("layout.xml.default.stylesheet", true);
// Stylesheet URL or none, default our xml.css
pref("layout.xml.default.stylesheet.url", "resource://xml.css");
// Script on/off: true or false, default true
pref("layout.xml.default.js", true);
// Script URL or none, default our xml.js
pref("layout.xml.default.js.url", "resource://xml.js");
Keywords: qawanted
Whiteboard: (py8ieh: test cases required)
Ok, I spoke with mpt about this on IRC in #mozui, and we came up with the 
following spec. Note that it adds no new prefs to the UI, because that is not 
going to help the user. (Of course, add as many hidden prefs as you like.)

If an XML document has no author stylesheet [1] no author script [2] and 
contains no elements or attributes in namespaces given in ua.css [3], then we
should display it as if someone had asked for the document's source instead of 
laying it per CSS.

Once the document is shown, we have to listen for mutation events to (a) update
the source view and (b) switch out of the source view if any of the conditions
listed above stop applying (e.g., a stylesheet PI is added to the document).

Things we should avoid doing:
   Inventing a totally new source view.
   Breaking XHTML or MathML.
   Making it hard to add extensions to ua.css without rebuilding.
   Killing dead the potential for DOM-based creation of styled XML documents.

Notes:
[1] There are various ways to add author stylesheets: style attributes in 
various namespaces, style elements in various namespaces, various different 
link elements in various namespaces, HTTP headers, presentational attributes 
on elements in certain namespaces, etc. I don't know how to test for this 
properly. For example, one way to add styles is to dynamically bind the root
element to an XBL binding that links to a CSS stylesheet. We have to be able
to cope with this case correctly.

[2] Similarly, scripts can be added in many different ways. The XBL case is 
possible here too, but that's not the only way. Adding event handlers via the
DOM is another possibility. Some elements and attributes in various namespaces
add script to the document, etc.

[3] The contents of the ua.css file can change depending on the build options
and user modifications at run time. For example, MathML is sometimes supported
and sometimes not, and all links (XLink included) are styled by html.css. So
again we can't hardcode this. The best solution I can think of is suboptimal and
is to check the CSSOM of the UA stylesheet and its kids when displaying the XML 
file in question. The ideal solution would be to crawl the DOM checking
getComputedStyle to find out if anything was styled, but that's just stupid from
a performance point of view.


Heikki: Please do not remove my markers from the status whiteboard or keywords.
Keywords: qawanted
Whiteboard: (py8ieh: test cases required)
>...
> then we should display it as if someone had asked for the document's source
> instead of laying it per CSS.

Not quite. If I choose View Source for an XML file, it should show me the file 
as plain text, the whole plain text, and nothing but plain text -- just as it 
should for any other file type. It shouldn't show me a fancy tree; the fancy 
tree should only be shown in the (non-view-source) style-less circumstances you 
mention.
> If I choose View Source for an XML file, it should
> show me the file as plain text,

But with colours (syntax highlighting)?

I'm saying there should be no "fancy tree", we should use view source (with 
colouring) instead. If authors _really_ want the opening and closing, then
we can add that to viewsource (no reason why clicking on tags in viewsource
shouldn't collapse their contents).

The reason we are doing this is to make people think that we support XML.
Currently people view XML documents in IE then Mozilla and our rendering makes
them think (incorrectly) we don't support XML.
> (no reason why clicking on tags in viewsource
> shouldn't collapse their contents).

How would this work? The source isn't necessarily indented, and there *should* 
be a way to see if an element is collapsed or not.
I am also more inclined (for the short term) to keep view source as is, and only
mess with the default view of XML without style/script. I believe IE is doing
this as well (view source -> Notepad still?). I believe it would be possible to
choose some compromise between the foolproof extensible (namespaces etc.)
solution and a straw man solution.

The best solution would probably be to have several levels of view source: 1)
Raw text as is, 2) Syntax coloring, 3) Indented, collapsible with syntax
coloring. Note that anything else beyond raw text would most likely mean parsing
the data which would lead to altered data. Today the situation is that we parse
view source, and do not display it as is (even without syntax coloring).

The default view source view would be 1), the default "no stylesheet XML
document view" would be 3). The view source window should have buttons to switch
between views. This would require so much work that I think it is outside the
scope of this bug (i.e. a new one should be opened for this).
Heikki's right. View source should show just the source. Any (optional) fancier 
presentation of source is outside the scope of this bug.
Ok, well, since mpt doesn't think it's confusing to have several different 
source views, I stand corrected... although I'm still not convinced that we 
need a "fancy view" at all. The only reason we are doing this is to make 
authors think we support XML when they give us an XML document whose correct 
output would be one long line of text. Doesn't what view source do already 
satisfy this need?

My other comments stand.
> mpt doesn't think it's confusing to have several different source views

Where did I say that? What part of `View source should show just the source' 
don't you understand? :-)

> Doesn't what view source do already satisfy this need?

If it does, that's a bug. View source should show just the source. Sure, it can 
change the colors, but it shouldn't change the indentation or other whitespace.
Where did I say that changing indentation and white-space would be good? Why
would "[changing] the indentation or other whitespace" "make authors think we 
support XML when they give us an XML document whose correct output would be one 
long line of text" any more than a loyal coloured view source?
Hmm... as I am now looking at the the source I am starting to lean more towards
rigging in view source window to show an XML document without stylesheet (CDATA
sections, processing instructions, comments, entities would cause serious
problems otherwise). How about, if we do not see any style information, we
present the user with a dialog:

This XML file does not appear to have any style information
associated with it. Would you like to open it in page source
view?

[x] Remember this decision for all XML files without
    style information.

[Yes] [No]

If the user answers yes, the simplest solution would be to fire the view source
command which would open the file in a new view source window. It might also be
easy to reuse the current window. I am not sure which I prefer, they both have
their pros and cons.

This would make it clear that we support XML and that we think it does not make
sense to try and view the file without a stylesheet, except as source view.

Then we could open new bugs to add different views to view source (raw, pretty
print).
Sounds great! (See my comments dated 2001-04-20 22:50 for the difficulties in
finding out if we have "style", though.)

I'm slightly concerned about popping up a dialog box (I can never work out which
of the dozen windows I have open is the source of the dialog when Mozilla says
something like "could not contact host x.y.z", and I don't see why this case 
would be any different) so how about this: when we detect the conditions that
make us think there is no style we display a (XUL) page like this instead:
    ____
   |    L\  This XML file does not appear to have any style information
   |<xml>|  associated with it. 
   |     |
   |_____|  [ View document without style ]  [ View source ]

Ok, so UI design is not my area. Over to mpt for better ideas...
Well, we use dialogs otherwise so it would be inconsistent to use the content
area for the message (although I agree with you that sometimes it is confusing).
So I do not think we can go there, unless we go and change ALL the cases were we
pop up dialog boxes when content area message would be 'better' (but please note
that if you have retrieved part of a document it is not nice to use the content
area for a message).

In any case, displaying a message in the content window is also tricky, since by
the time we would be able to display the message we would already have displayed
the original document...
Being paranoid I wanted to save my current work. I think I have every case
covered where we do not want to ask (except for scripts 'cos I am not sure about
them, but one line addition only). Putting up the dialog is easy, but right now
I seem to get into a hang situation (I can not dismiss the dialog). That might
be due to the debugger or the fact that I do not have a parent window for the
dialog.

Because this thing would will affect l10n I do not know how likely we are to get
this in.
Status: NEW → ASSIGNED
You shouldn't use an alert which requires the user to make a decision, unless 
the user is in danger of some sort. That's clearly not the case here. And you 
especially shouldn't throw alerts for stuff appearing in the Navigator content 
area, since that will aggravate people who are trying to flick through the 
session history.

Fortunately, in this case showing an alert is unnecessary, because the
alert-less UI is already there. If the user wants to see the fancy expandable 
tree, they just look at the content area of the window. If, on the other hand, 
they want to see the raw text source, they just need to choose `View' > 
`Source'.

Meanwhile, Hixie's suggestion of a header in the content area, giving a short 
explanation of why the XML is appearing as a fancy tree, is an excellent one. 
It is true that we don't do this for other types of errors currently, but that 
is what bug 28586 is about.
Localization freeze in effect, moving to next milestone where this can be fixed.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
There is a good example of a 'default' stylesheet in the apache xsl-parser. Yes
it is an .xsl and is currently IE-centric. With some (minor) changes it will
work with Mozilla as well. It does everything from coloring,
collapsing/expanding etc. Maybe the guys (and girls?) from Apache may let us
borrow it, expand it and ofcourse donate the result to back to them... 

If you all are interested I'll see if I can adapt it to work with Mozilla.


Interesting...

Unfortunately I do not know much about XSLT. Peter, do you think using an XSLT
stylesheet here could work?
Attached file default xsl like IE (obsolete) — 

    
    

    
  

      
      
      
      

        Attached file
          
        first working example for Mozilla (obsolete)
        — 
      

    


  

    
    

    
  
The attachment contains an example of how the 'default' stylesheet could work.
Because of two limitations in XSLT in mozilla (no css and javascript from an
xsl) an example html file is included. That is generated from the .xml and .xsl
file with Xalan. (sorry no standalone Transformiix here ;-) )

This example is an adapted version from the one that comes with Xalan and seems
to originate from the IBM Lotus xsl project.

Please add comments here.

    
    

    
  
Just my 2 cents: to be honest I think the current view-source functionality in
the main window would be fine. With syntax highlighting it's obvious we support
XML.... anyway, just an idea. To be honest the tree thingy in IE doesn't do much
for me. I prefer having the original layout exactly.

    
    

    
  
> Just my 2 cents: to be honest I think the
> current view-source functionality in
> the main window would be fine. With syntax
> highlighting it's obvious we support
> XML....

Not exactly obvious, no.

And see <URL: http://www.finetuning.com/finetuningfaq.html >:

> What's the best XML Browser?
>
> Netscape 6, has little or no XML functionality that isn't
> closely-tied to its application platform, zero XSLT support
> (and apparently serious no plans for adding it), and no
> default view for an XML document. So if you open a file that
> isn't associated with a CSS style sheet, it just dumps the
> text. 
> 
> IE5, on the other hand, *is a useful XML Browser from a
> developer's perspective because it provides an easy way to
> access and view XML documents when you are testing or
> debugging them*. [my emphasis]


    
    

    
  
Aw, and I thought I had been working on XML for a long time. Seems like all this
(that is supported by Netscape 6) is not XML, or not worth mentioning:

* display XML documents,
* format XML with CSS,
* manipulate XML with JavaScript,
* load XML as data,
* do some XHTML,
* do simple XLinks,
* do Namespaces in XML,
* build UI with XML language (XUL),
* build sidebar with RDF (XML language),
* etc.

(And did you know that IE has crappy support for formatting XML with CSS, parses
entities wrong, does not support XLink at all...)

If we knew this beforehand, we should have just implemented

* XSLT and
* view source view of XML

to make the world happy.

Can we have a new component, Banish incorrect information?

    
    

    
  
Yes, that would be "Evangelism". Feel free to file a bug! :-)

Heikki: Any progress on fixing this bug in one way or another? After 0.9.1 ships
we should have some time before the next Netscape l10n freeze.

    
    

    
  
Haven't worked on this at all. But I just had a chat with Nisheeth. It seems
that as long as we do not do incremental layout in XML (this should be fixed) we
could build the content model for the page as we first load it and display a
message that no style available and ask what the user wants to do instead. If
the user wants to see the source, we could discard the content model and load as
view source. Otherwise we'd discard the current message content and put the
already built content into place (frames only need to be built).

Filed bug 84546 on Evangelism to get the information on finetuning corrected ;)

    
    

    
  
I like that. So, if an XML document has no author stylesheet [1] no author 
script [2] and contains no elements or attributes in namespaces given in ua.css 
[3], then we would display the following in the content area:
    ____
   |    L\  This XML file does not appear to have any style information
   |<xml>|  associated with it. 
   |     |
   |_____|  [ View document without style ]  [ View source ]

While that is shown, we have to listen for mutation events to switch out of the 
source view if any of the conditions listed above stop applying (e.g., a 
stylesheet PI is added to the document). If the user clicks [ View source ], 
then we don't worry about monitoring the source. If the user clicks the first
button, then again we don't need to worry, since it would Just Work (as now).

Actually, we could even do that on the fly, no need really to wait for the 
entire content tree, is there?

As I mentioned bfore, we should avoid:
 * Implementing a totally new source view.
 * Breaking XHTML or MathML.
 * Making it hard to add extensions to ua.css without rebuilding.
 * Killing dead the potential for DOM-based creation of styled XML documents.

Notes copied from my comments earlier:
[1] There are various ways to add author stylesheets: style attributes in 
various namespaces, style elements in various namespaces, various different 
link elements in various namespaces, HTTP headers, presentational attributes 
on elements in certain namespaces, etc. I don't know how to test for this 
properly. For example, one way to add styles is to dynamically bind the root
element to an XBL binding that links to a CSS stylesheet. We have to be able
to cope with this case correctly.

[2] Similarly, scripts can be added in many different ways. The XBL case is 
possible here too, but that's not the only way. Adding event handlers via the
DOM is another possibility. Some elements and attributes in various namespaces
add script to the document, etc.

[3] The contents of the ua.css file can change depending on the build options
and user modifications at run time. For example, MathML is sometimes supported
and sometimes not, and all links (XLink included) are styled by html.css. So
again we can't hardcode this. The best solution I can think of is suboptimal and
is to check the CSSOM of the UA stylesheet and its kids when displaying the XML 
file in question. The ideal solution would be to crawl the DOM checking
getComputedStyle to find out if anything was styled, but that's just stupid from
a performance point of view.

    
    

    
  
If the document already has no scripts attached to it, how can any script modify
it then? Doesn't the security manager prevent this?

Can you attach XBL/XUL/CSS whatever to a document if it does not load any
stylesheets (and does not have embedded style blocks in it)?

I also checked out the XSLT stylesheet, and that looks pretty neat. (I have no
idea what the second attachment from Ronald is, seems like binary data to me). I
edited the XSLT attached so that the style is loaded from a separate CSS
stylesheet, and lowercased the generated element names, and now the
transformation shows up nicely. Scripts still do not work.

The XSLT approach seems nice as it would provide almost exactly the same view as
IE (and others mimicing IE), somebody has done the work of creating the
stylesheet already (although I am not sure if we can use this one because of
potential license restrictions), and we could probably leverage the XSLT
plumbing to implement this with no more difficulties than any other way. There
are still some problems with scripts (and embedded style), but peterv is working
on them.

    
    

    
  
Any page from the same domain can modify an XML page, AFAIK. I'll create a test
case for this now.

    
    

    
  
heikki: Ok, here is a first attempt at a demo test case:
   http://www.hixie.ch/tests/evil/xml/001.xml
This case musn't regress when we fix this bug. :-)

    
    

    
  
Here is another demo, it uses frames instead of window.open:
   http://www.hixie.ch/tests/evil/xml/001.xml
Both of these tests are purely XML based, no text/html content is involved.
Keywords: qawanted → mozilla1.0
Whiteboard: (py8ieh: test cases required) → [Hixie-P4]

    
    

    
  
Bummer! Who made JS work this way anyway, we should disable it to make poor
programmers life easier ;) ...

Hmm... Actually, a document observer can easily catch the modification attempts
and even though the script from the other window might try to modify our message
document it could forward the attempt to the real document, and then switch
views. Unfortunately this is confusing to the user: first we are asking for his
decision, but if the script in the first window (in your example) modifies the
document in the second window while we still have the message up there we would
replace the message with the real document. Or should we in such a case change
the message to state that the document has been changed by a script and that it
would make more sense to view normally?

I am not sure if catching style changes is that easy... Nor do I have any ideas
how to detect namespaces we have styles for (but I can easily detect if we have
an implementation for a namespace).

Could you make the first document HTML, so we could test how IE behaves?

    
    

    
  
heikki: Ok, here's the first document as HTML:
   http://www.hixie.ch/tests/evil/xml/001.html

Unfortunately, it won't help you. IE doesn't support XML at the DOM level. They 
don't provide document.createProcessingInstruction and their window.open() 
doesn't return a window object that has a DOM that is editable in the XML case.

In fact, if you look at the following test case, you'll see that their DOM 
actually contains the DOM for their transformed document (which is very wrong
per W3C, since there is no default transformation applied and XSL has no concept
of UA stylesheets):
   http://www.hixie.ch/tests/evil/xml/003.html

Trying to dump the DOM of an XML document that starts off with a processing
instruction and some XML returns you an HTML document with a <LINK> element for
each XML stylesheet PI, and the XML fragment as unknown tags as children of a
BODY node. See:
   http://www.hixie.ch/tests/evil/xml/004.html

In the case you give, I don't think we should change the message to state that 
the document has been changed by a script, since that would break this scenario
just as much as the original message. The point is the message should only ever
appear if there is no reason for the document to be displayed normally.

Therefore I think we should switch straight away if we detect a change. Even
that is not ideal because of the flicker it causes.

    
    

    
  
Heikki: the second attachment is a zip file (or tar.gz, don't remember) where
besides the layout/coloring all the scripts work so you can actually collapse
and expand nodes.

Target Milestone: mozilla0.9.2 → mozilla0.9.3

    
    

    
  
*** Bug 87181 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 66983 has been marked as a duplicate of this bug. ***

    
    

    
  
The latest patch does the XSLT transformation with the files Ronald provided (JS
still does not seem to work for me). The behaviour is controlled by a pref,
there is no UI yet. I have not yet checked what happens if a script tries to
work on the document from another window - in fact I do not know (yet) for sure
what the script sees (the transformed document or the original).

    
    

    
  
Seems like we also loose the original document in transformation. At least
Hixie's samples show that we access the transformed DOM :(

Peter, is this a known problem? Is it so by design? I know the DOM WG has
discussed this problem, but there are no methods/properties that could be used
here (to access either the original or transformed document) that I know of.

    
    

    
  
We discussed this today at Nisheeth's staff meeting, and came up with a new idea.

What if we added an item to View menu (or View > Use Stylesheet) for Tree View
or some such name, which would apply the default XSLT transformation? Power
users could even diddle with their default transformation to get different
output! It might even work for documents that have styles and scripts in them...
We could display a warning to the user that a transformation will take place
etc. At the moment I don't think it would be possible to switch back to the
normal view without reloading.

After all, the tree view is mainly useful for developers; end users should never
even see nor care unformatted XML.

Peter, can this be done without the content sink and changing the original
document (i.e. without inserting xml-stylesheet PI)?

    
    

    
  
Heikki, it should be possible using nsIDocumentTransformer. I know I tried this
about 10 months ago, but Transformiix wasn't quite up to it then. The only
tricky part might be switching the original tree with the transformed tree. I'll
try to look into this tomorrow or over the weekend.

    
    

    
  
If we add a menu item to the View menu it should be done as part of bug 6782 as
one of the default local user stylesheets that can be applied. This would make it 
totally configurable which would be a big bonus.

    
    

    
  
Heikki: Does the JS work if you run it standalone, e.g. from disk? It does for
me on the 2001070421 build on linux. What is the pref to activate this or isn't
it in the nightlies yet? 



    
    

    
  
Heikki: Sorry for being unclear. The reason it does not work (yet) on xml files 
is that Mozilla does not load a .js/.css file in the result document.

If you save the transformed document as html and then load it from the same
location you'll see it working. There is an example html file in the attachement
36257 (05/26/01) 


    
    

    
  
Small correction: Mozilla *does* load external .css in the result documents.
Just no .js nor embedded scripting (see bug #59912)

    
    

    
  
> After all, the tree view is mainly useful for developers; end users should
> never even see nor care unformatted XML.

Sure, but then why does this bug exist in the first place? Because developers
expect an unstyled XML document to be shown in a Web browser as a tree. A
simple, Internet-Explorer-like, non-configurable, non-themeable,
non-content-pack-able, tree.

Defaulting to raw text, and making developers jump through hoops (menu items,
alerts, whatever) in order to get the tree which they are expecting, will just
annoy them. If they want raw XML source, that (by definition) is what View
Source is for.

    
    

    
  
They only want the XML tree because that is what IE has taught them to expect. The
reason this bug exists is that reviewers have loaded XML pages in Mozilla, seen
them rendered exactly as per CSS, and thus concluded that our support for XML is
worse than IEs. If we display the coloured view source instead of the pretty tree,
that will solve that problem. The best solution, IMHO, is what I have described
several times above, namely displaying a message in the content area explicitly
stating that we support XML. See my 2001-06-07 22:43 comment for a detailed spec.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

    
    

    
  
Often requested feature.
Keywords: nsbranch+

    
    

    
  
Heiki - This is marked as an "Enhancement" right now, so I have a couple of
questions: 1) What's the ETA (i.e. Will it get in before 08.31)? 2) Is this a
"stop-ship" for TM0.9.4?

    
    

    
  
I don't know the ETA yet (and I am doubtful this could make it before 8/31), and
this is certainly no stop-ship. But this is often requested feature so I would
like to try and work on this until the last possible moment. I have a few
approaches I can still try that shouldn't be too scary. The XSLT approach still
looks good to me, but there are at least two open XSLT bugs (one of which has no
workarounds) that might prevent us deploying that solution for 0.9.4. peterv is
still working on those, however.

But I  have a couple more important bugs on my list right now so work on this
has been stalled.
Keywords: nsbranch+
Target Milestone: mozilla0.9.4 → mozilla0.9.5

    
    

    
  
Sorry, I'm a foreigner here. But as a user and web developer I'd like to give my
opinion.

The result of all this should be a solution that is the most useful one to the
most people, without crippling mozilla regarding to its standard support and
correctness. As a web developer I'd like to see the XML document (and every
other content-type) shown in the best posible way. If I browse a vcard
content-type I'd like to see a business card (and the vcard source in
view-source). If I browse to a text/xml document I want it to see it in the most
useful way. A non-styled XML document is a neutral piece of infomration. A
collapsable tree is better than a simple colorized tree or the current
everything sticked together view, period.

The argument about "mozilla styles the document using CSS" is IMO wrong. There's
nothing in any standard that says that CSS should be used in case there's no
http header or PI saying it. In this case, mozilla is deciding a way to format
the document that will clearly yield unusable results in every case.

So, please... let mozilla show a non-presentational XML document in the most
rich and useful way, whatever form that is (collapsable tree of tags? tree of
funny ballons? xpath tooltips when moving the mouse over the tags?).
thanks and sorry for the intromission (and excuse my bad non-native English).

Target Milestone: mozilla0.9.5 → mozilla0.9.6

    
    

    
  
*** Bug 14587 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 104997 has been marked as a duplicate of this bug. ***

    
    

    
  
A thought.  Once the DOM Inspector is on by default, it sounds like it would
satisfy all the things people want in this RFE... all that would need to happen
is hooking into it for certain kinds of XML (and we seem to already have code to
detect when this would be necessary in attachment 36257 [details]).
Target Milestone: mozilla0.9.6 → mozilla0.9.7

    
    

    
  
DOM Inspector is now in the default builds (bug 102574).  I like the proposal in
comment #65.  Any reasons not to go forward in this direction?

    
    

    
  
I like the idea, too.
Lets do it! :)

    
    

    
  
I think the DOM Inspector is great, but not for the average user. He/she (it?)
does not want to know how an xml document is decomposed in dom.

R.

    
    

    
  
Yes, I think using the DOM inspector for this is a great idea! Don't worry about
the average user thing - as has already been pointed out, average users should
never see raw XML.

Having a DOM inspector would not only be very useful, but also totally blow IE
out of the water! It'd show people that Mozilla really is the premier platform
for web development.

It gets my vote.

thanks -mike
Target Milestone: mozilla0.9.7 → mozilla0.9.9

    
    

    
  
I am again working on this. I can now display a message in the content area, and
have some ideas how to put the original document through transformation from there.
Keywords: nsbeta1 → nsbeta1+

    
    

    
  
Would anyone be willing to create an XSLT stylesheet for the default view? I
don't think we can use the one already attached here because of license issues
(but if anyone can prove me wrong that would be great).

Status: I currently am in a situation where I display the message to user (this
is XML, what do you want to do), but for some reason I have not yet been able to
get the scripts to run in this dynamically created document. Once that is
cleared next step is making us go through the transformation.

    
    

    
  
I think this stylesheet mimics IE's, rather than just copying it outright.  It
might be best to create a new one- that IE one isn't the most useful one to use.

    
    

    
  
Any suggestions? Then I can see what I can come up with.... 

A Nesting kind of like XMLSPY does could be an option... Let me know

    
    

    
  
My two pence:

  DOMInspector: Very useful for DHTML (it's ironic Mozilla has so great tools
for development of DHTML) but almost useless for work with pure XML. As someone
pointed out average user should never see pure XML, but for someone working with
XML very much IE way is good. People working with data in XML form are not
interested in their DOM structure. (Anyone has ever parsed non-indented SOAP
messages with a lot of SOAP-insignificant data? You would praise for colapsable
view. And simply on Windows IE is the quickest and cheapest way.)

  ViewSource: Much more useful than any other ViewSource ever, but also slow and
not customizable.

  My conclusion: When JS from XSLT can work (and Ranges are working properly and
so on ^_^) we can build very powerful yet customizable XML viewer on top of
Mozilla which would satisfy almost everyone needs. I'm pretty sure I can find
some time to do so if we can settle on something.

    
    

    
  
I'm confused by that last comment... "DOMInspector [...] almost useless for work
with pure XML" ... "You would praise for colapsable view".  Which is exactly
what the DOM inspector gives you.... a collapsible tree view of your XML
document with the ability to see the attributes on various tags and the like. 
Am I missing something?



    
    

    
  
I'm creating webpages almost ten years and last two years XML (data in XML -
it's important!) is my daily work. I run DOMInspector when I'm cretaing some
non-trivial HTML layout and I run IE when I want to see XML files. Simply
DOMInspector is by far the best thing if there is something broken with your
page (your scripts) and you want to track it down, and IE is by far the best
thing when you want to get "complex" view of XML data. Just my experience.

Simply ViewSource with some handy addings (~ what IE does) is from "data-view"
much better then DOMInspector (data separated from the markup, #text-nodes
everywhere you look etc.).
Target Milestone: mozilla0.9.9 → mozilla1.0

    
    

    
  
*** Bug 127920 has been marked as a duplicate of this bug. ***

    
    

    
  
ADT3 per ADT triage.
Whiteboard: [Hixie-P4] → [Hixie-P4][ADT3]

    
    

    
  
*** Bug 132751 has been marked as a duplicate of this bug. ***

    
    

    
  
taking...
Assignee: heikki → nisheeth
Status: ASSIGNED → NEW

    
    

    
  
In what way is an XSLT-based solution better than embedding the DOM inspector
into the window/tab? 

I noticed that the DOM inspector does not display text nodes inline in the tree
view, but that is an enhancement that could be made to the DOM inspector, I believe.

    
    

    
  
I agree with Brian

    
    

    
  
Changing QA Contact
QA Contact: petersen → rakeshmishra

    
    

    
  
I was introduced to this discussion today. From my view this is all very clear:

If I want XML displayed in fancy way I add some style information. If I do not
want any rendering I do not include any styles. I consider it harmful to the XML
standard if there would be any default view of an XML file.

I could only imagine one solution: If a user uses a popular DTD or schema -
maybe the developers of such DTD have a defautl stylesheet on a web-page.

So Docbook-XML could be displayed nicely without a stylesheet. But there we have
the same problem: We do not know what the author intended. Just imagine that he
HATES blue ;-) - and Mozilla displays the elements in blue! Oohhh! ;-) he will
hate Mozilla for that.

The discussion here indicates one thing very clearly: That there are different
viewpoints how XML SHOULD be displayes by default. I think this can only lead to
the conclusion that no default display other than displaying the contents of
elements should be considered.

I also can not see why a web developer wants to view an XML source with a
browser? Don't they have an editor or parser? Nonetheless I think it is good to
provide the possibility for users to link to a default stylesheet (CSS/XSL) may
via the "Apearance" preferences.

Summary:
If I publish an XML document without style I do not want it to be displayed with
any decoration. This is something that never could be reached with any kind of
default fancy output.

PS: If really many people want fancy plain XML, maybe it would be good to be
able to browse with the source code window (add an address bar to it) .

cu,

Thilo

    
    

    
  
If the author of an XML document doesn't specify a style for their XML document,
it means they don't care. It means it will be displayed in whatever default way
the tool being used by the user displays. I use IE to view XML because I like
the default way it displays XML when there is no specified style. OTOH I would
love to use Mozilla to do this, except that currently, I hate the way Mozilla
displays XML by default. Please help me never use IE again. Believe it or not,
Microsoft set the de facto standard for plain XML display by putting IE into 90%
of the population and having it work the way it does. I'm not saying this is
best way to do it, I'm just saying that this is what most people are now used
to, and probably what they expect.

I think creating an config option to have Mozilla behave the way it does now
(just displays the text contents between each tag) and similar to the way IE
does it would be a great feature.

    
    

    
  
And if you think about, Mozilla technically doesn't display XML right by
default. Why? Because in XML, spaces *do* matter. Mozilla shrinks all the
whitespace as if it was rendering HTML. So someone could actually use this to
say that Mozilla doesn't properly support XML.

    
    

    
  
See, the reason this is an issue is because only displaying the content of the elements gives the  very strong impression that Mozilla "doesn't understand XML".  As an XML developer myself, I will  contest that "view source" in an XML file is not convenient enough.    The reason why I personally am voting for this feature is because right now there seems to be a  shortage of tools that are able to conveniently "pretty-print" an XML file from HTTP, also allowing  expanding/contracting, highlighting, and all that good stuff.  IE does this, and it is very easy and  nice (although possibly against the grain of the specs, as you say).  View-source does the  highlighting, but without the pretty-printing of whitespace, it is pretty useless when looking at the  output of pretty much any type of automatically generated XML.    View-source and the DOM-viewer also require one more click, which requires XML developers to (1) know  what to click and (2) be satisfied with not being able to quickly hit "refresh" to test changes to  their output.  Also, the DOM-viewer, as already discussed in this bug, doesn't display text nodes  inline, which might turn some people off.    Why can this not be configurable, and have the best of both worlds?  A simple pref, even if it is  hidden (although not preferably), that lets the user set the default stylesheet for a given mime-type  (default text/xml and application/xml).  A stylesheet that renders similarly to the one in IE should  be included with the distribution, and documented.  The default setting could be to have no default  stylesheet, and fall back on displaying only elements' content (although personally I think that  shouldn't be an option, because in XML the element names and attributes are also very relevent to the  data being displayed, and to not display that extra information is bad.  But that's just me).    Mozilla has the potential to be an awesome platform for XML development, especially since it does a much better job that IE with cache handling.  But almost everybody I know  doesn't even know that using XML in Mozilla is possible (seriously), for the simple reason that it  doesn't pretty-print the XML.  This is a very big failure, with a very simple fix.  Why not make 90%  of the XML developers in the world happy? 

    
    

    
  
> I also can not see why a web developer wants to view an XML source
> with a browser? Don't they have an editor or parser?

Thilo, this is like saying that the HTML "view source" is is useless
because you have an HTML editor. Many server-side applications
nowadays generate XML on the fly, as an end product or more often as
part of a processing pipeline (think Apache Cocoon for example). Being
able to access such XML contents through a browser UI is invaluable
for debugging such applications.


    
    

    
  
Lynx has a beautiful source-browsing feature (you can reload page while viewing
source). I think Lynx is better for XML developers . I am not voting für Lynx
against Mozilla on every level.
But see, this is not a matter for simple users. If people call themselves
developers they are surely able to install a version of Lynx. I also said, taht
an enhanced source browser would be acceptable for me.

But I would vote totally against any default display somehow only because IE
began to make a false behaviour. Why should I use Mozilla if it behaves (wrong)
like IE? I think Mozilla should be more close to the standards.

Regarding white space I would say there is a need to be able to change the
behaviour of the browser (see also:
<http://www.oreillynet.com/pub/faqs/xml_faq_space> ). A good browser allows a
user to change the default behaviour. The good thing is, if there can not be
assumed any "default behaviour" is, that authors are forced to attach
stylesheets,... I am sure we can easily emulate IE behaviour with a stylesheet?
Why not an option "emulate IE XML display"?

I fear that if authors think that the behaviour of IE is correct we will see a
lot of pages depending on exactly this feature.

We should not forget: XML is not HTML which had a default layout. This leads to
obstruction of progress and not forcing the use of stylesheets (which are
actually freeing XML authors).

So there may be some arguments for other display options but I do not see any
good in changing Mozillas default behaviour, except that this would be a
set-back. I also can imagine that user will begin to change the default look a
bit - and not starting a stylesheet from scratch - so depending on a fancy
Browser to display their XML correctly.

Anothere thing: There is nothing won if only Mozilla and IE display XML the same
way. Only if every browser would do so, authors could depend on it.


PS: I only use Mozilla and sometimes Lynx for XML development as you might have
guessed ;-).

cu,

Thilo


 

    
    

    
  
We already have a UI spec for  this, it in comment 37 in this bug.
Whiteboard: [Hixie-P4][ADT3] → [Hixie-P4][ADT3] see comment 37

    
    

    
  
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-

    
    

    
  
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+

    
    

    
  
*** Bug 145156 has been marked as a duplicate of this bug. ***

    
    

    
  
Now c'mon. It's a sad, sad day when MS's bundled remotely exploitable html
rendering piece of flacid man-flesh can properly (and keenly) display XML and
mozilla can't.

As far as relying on lynx (a ****-filled clownshoes, .. I digress) I'd sooner
telnet and issue a GET.

I can offer any number of questionable barters in exchange for your attention to
this matter. Thank you again, Mozilla developers, for your continued efforts.
May you overthrow the dominance of IE and scatter it's entrails gleefully.

    
    

    
  
> ...properly...

Just for the record, Mozilla renders XML within the specs, more so than IE.
But yes, it would be nice if we could implement what's described in comment 37.

    
    

    
  
Here's why I think Mozilla needs this: In my application, we have thriod parties
sending xml requests to an insurance quotes system. We generate the response
message and send that back to the 3rd party. That xml is never displayed to the
user, so when we send it back, it's one long string of xml, with no style sheet
attached. As a developer, we have a web page that simulates the third party, in
which we can type, or paste, an xml request message, submit it to our servlet
and back comes the xml stream. If it is displayed with no style at all, it's
just displayed as one long stream of text, not at all pretty and not at
readable, wheras IE "pretty prints" it and allows me as a developer to easily
examine the various nodes and their values. Yes, of course I could cut and paste
this into another tool to "pretty print" it, but it's SO convenient to do it
right there in the browser. I think it would be a huge help to have Mozilla fall
back to a default "pretty printed" display of the xml if no style sheet is
specified.

    
    

    
  
Hi all ... 
  I've seen that this RFE was first targetted for 0.9.1.  It now seems to be 
targetted for 1.0 .  Mmmmm ..... 
  Now that Mozilla 1.0 has been and gone, is anyone able to give even an 
_approximate_ ballpark release that this fix may be in?  I just ask because 
this fix has been on the list since Jan 2001. 
 ( I'm sorry - I'm not wanting to sound whiney :-),  but it's been here for 
quite a while ... )  Thanks in advance for your comments!  ( and **VERY many 
thanks** for your great work so far ....  




    
    

    
  
I would like to know as well if and when we can expect 'pretty XML' in Mozilla.
In our company XML is used for almost everything and lots of my colleagues
were really interested in Mozilla and started using it. Until... the questions
came in asking "hey, how can I get Mozilla to display my XML in any usable way?".
Sad to say but very understandable from their point of view they went back to using
IE again (at least for work-related stuff) because of the incredible ease-of-use
to just be able to either get HTML or pretty XML from our (web)services without
having to switch to another view or application. And no, adding stylesheet info
to our XML is NOT an option.

This bug gets my vote! :-)

    
    

    
  
An idea I had: it would be easy to improve on what IE already does with XML.
In a prefect browser I would have a list of namespace->stylesheet mappings 
where I could tell the browser which stylesheet to use to render a certain XML 
document (why use the stylesheet the author has defined? I might not have 
access to it or I might just not like it). In that list I should be able to 
define which stylesheet to use (if any) if none of the others match.

One might ask why it should be possible to define this for XML while something
similar doesn't exist (and maybe isn't needed) for HTML? Why can't you always
define a stylesheet for your XML? Well I don't know about the rest of you but
we use XML in a lot of ways, many of which have no direct use as a displayable
document. So many (if not most) documents just hold data and have no stylesheet
defined for them (and don't need one!). Of course we could define a standard
stylesheet ourselves and attach that to all our XML documents but that would
mean that I can't just send an XML document to somebody else, I would always
need to send the stylesheet as well (this because even if the other uses IE the 
XML would not display because IE will try to use the stylesheet). Besides the 
basic fact that that particular XML document is not for displaying so WHY am I 
forced to pollute it with layout information?

So what do y'all think? Is the above suggestion a feasible idea?

    
    

    
  
It's almost impossible to do that while still handling the dynamic cases.

We already have a proposed spec for this which handles all the cases fine, see
comment 37.

    
    

    
  
Most of the comments argue that having a default stylesheet will disable nice
features such as dynamic behaviour. I find it strange the general case must get
out of the way for the specific case.

My opinion is that if you want to do something special (i.e. ecma script in a
xml file) you should indicate that somehow (with a stylesheet?). If your xml is
just data, then you should not have to add a stylesheet.

Status: NEW → ASSIGNED

    
    

    
  
The general case for which behavior is completely undefined should not get in
the way of the specific case for which behavior is clearly standardized. 
Developers should be able to rely on us implementing standard APIs correctly...

I fail to see how ECMAScript in an XML file is "something special", any more so
than anything in an XML file that is not in the same namespace as the main
file....  In fact, I would argue that using a web browser (!) to read arbitrary
XML is the really odd thing to do. I would want to use an application familiar
with the XML vocabulary in question that would actually be able to display the
information in a useful fashion, not just as a raw tree.

    
    

    
  
You are right about implementing only that which is clearly defined but then 
you will probably also admit that:

a) the current way Mozilla handles unknown XML is not clearly defined and next 
to useless

b) it would be great to be able to register other namespaces (besides the 
current XHTML, MathML and RDF ones) with their respective stylesheets. XHTML 
and MathML documents don't contain PIs either and they display correctly.

I did understand that currently adding support for other namespaces is only 
possible by making a special Mozilla build, which is a pity. I hope that in a 
future version (maybe aided by discussions as this) a more dynamic system will 
be made possible.

And when we have such a system it might not be such a big problem to assign a 
stylesheet to all unknown namespaces thereby enabling a default view for all 
XML documents. I don't mind to have to install that stylesheet as a separate 
option if there is so much oposition to making this a standard Mozilla 
feature :-)

I agree that a web browser is not the best application with which to manage XML 
documents, but it is the best application to VIEW documents in the best way 
possible when served over the Internet. If it was possible to install a plug-in 
which would show XML the way I wanted I would not bother you anymore in this 
list but the fact is that that isn't an option. So I'll continue to try to get 
the best possible user experience (and developers are also users :-) out of 
Mozilla. 


    
    

    
  
I would argue that sometimes it is advantageous to use a web browser to view 
XML. The most obvious example is when developing XML Web Services, where XML 
documents are returned by an HTTP server. What better application is there for 
viewing a document of a particular URL (HTTP GET/POST)? A web browser. I 
develop web services almost exclusively and I use IE constantly for debugging 
the output from my application, not for a lack of other applications that can 
perform the task, but because it offers the simplest UI for querying a URL 
(favorites, shortcuts, history, etc...) and provides a great representation of 
the result.

I see no reason why mozilla can't provide this:

1) type URL
2) see XML

    
    

    
  
> In fact, I would argue that using a web browser (!) to read arbitrary
> XML is the really odd thing to do.

Unfortunately, as MPT pointed out in comment 56, a certain market-leading web
browser has spent at least the last couple of years teaching people that it's a
perfectly NORMAL thing to do.  The cat's out of the bag, and we aren't going to
get it back in.  



    
    

    
  
Guys. We're already convinced. We want to fix this. We have a spec (comment 37).
You are preaching to the choir. Adding more and more comments to this bug isn't
helping anyone. Thanks.

    
    

    
  
Why are the choices in the spec limited to "[ View document without style ]  [
View source ]" Why not provide a list of stylesheets that the user can pick
from? I think that would be more useful.

The stylesheets (or symlinks) could be stored in some folder(s) that Mozilla
knows about.

    
    

    
  
> Why are the choices in the spec limited to "[ View document without style ]  [
> View source ]" Why not provide a list of stylesheets that the user can pick
> from? 

I mean, in addition to "View document without style" and "view source", provide
a list of stylesheets to choose from. Also, I would like to have a choice [View
with DOM Inspector].

    
    

    
  
Sorry Ian, but like we discussed in our email conversation I don't think #37
adds anything to the current situation besides a shortcut to the current two
options:

a) display with the current stylesheet which I can't imagine anybody really using

b) display like current View Source window does which is kinda nice but doesn't
do a very good job of badly layouted XML (generated XML is mostly like that).

Of course b) could be fixed by improving the way View Source works, but still I
feel Mozilla could be given some great features here which would set it apart
from the rest and even improve upon its rival. If we have to do it, like gavin
says because people expect it let's make it even better!

    
    

    
  
IMHO the proposal of comment #37 could be rewritten as:

[ View document in a completely useless way ]  [ View source ]

Why include an option that we already know nobody will want? Just to say "we are
better than you"?

I think Mozilla shoould display that XML file in the best way posible that shows
it's structure, namespaces, with some nice [expand all] [collapse all] buttons
and things like that.

This is not a thing of "purism" as there's no standard which says in which way
or with which stylesheet language an XML file with an unknown namespace and with
no recognized PI's should be shown.

Besides, I don't agree with "why would you expect to use an web browser to view
an XML?" argument. I expect a web browser to do a decent job to view each
content-type and file format which belongs to the "field" of web
develpment/browsing. We expect a web browser to render an image/jpeg resource
even if it's specified directly in the URL-bar (not referenced from an <img>
tag). XML files are a new one of those formants which are just another component
to build the web. Mozilla should do its best to show it in a useful way.

[ sorry for the spam =) ]

    
    

    
  
There are some good suggestions here. Adding some possibilities, like:
    ____
   |    L\  This XML file does not appear to have any style information
   |<xml>|  associated with it. 
   |     |
   |_____|      (( Apply the pretty printer stylesheet to this document ))
                ( View source )  ( View document in DOM Inspector )
                ( View document without style )

...would be good. Of course, all the mutator event stuff listed in comment 37
should still apply, so that if the page is changed, it is correctly displayed.


> I don't think #37 adds anything to the current situation besides a shortcut to
> the current two options

Indeed it doesn't, the idea was to not encourage people to send raw XML using
unknown semantics over the web, while making sure that users did not assume that
we don't support XML.


> This is not a thing of "purism" as there's no standard which says in which way
> or with which stylesheet language an XML file with an unknown namespace and 
> with no recognized PI's should be shown.

Actually, CSS does.

    
    

    
  
>> I don't think #37 adds anything to the current situation besides a shortcut 
to
>> the current two options
>
>Indeed it doesn't, the idea was to not encourage people to send raw XML using
>unknown semantics over the web, while making sure that users did not assume 
that
>we don't support XML.

But who are we to decide what "XML using unknown semantics" is? There's lots of 
XML out there with clearly defined semantics that are just not supported by 
Mozilla. On the other hand there is the default behaviour (and still supported 
in proposal #37 and #111) which assumes that running any unsupported XML 
document through some kind of default Mozilla stylesheet is actually usefull 
(which it might be in 0.1% percent of the cases).

And who are we to discourage people from sending XML documents over the web?

>> This is not a thing of "purism" as there's no standard which says in which 
way
>> or with which stylesheet language an XML file with an unknown namespace and 
>> with no recognized PI's should be shown.
>
>Actually, CSS does.

Sorry, but I don't think that the CSS standard has anything to say about this. 
If I want to use XSLT to display my document I can. That would be something if 
the CSS standard would start telling me which stylesheet language to use!

If we really need to have a selection I would just go for this:

   |    L\  This XML file does not appear to have any style information
   |<xml>|  associated with it. 
   |     |
   |_____|      ( Apply the pretty printer stylesheet to this document )
                ( View source )  ( View document in DOM Inspector )

But knowing that I can get to the View Source and DOM Inspector directly from 
the menu I would want an option to apply the pretty printer stylesheet without 
asking me. Which would make the entire page obsolete.

    
    

    
  
ok, here's an updated spec that takes recent feedback into account.


If an XML document has no author stylesheet [1] no author script [2] and
contains no elements or attributes in namespaces given in ua.css [3], then we
would display the following in the content area:
    ____
   | __ L\  This XML file does not appear to have any style
   |<xml>|  information associated with it. 
   | \/  |
   |_____|  The document tree is shown below. You may also see
            the _original_unstyled_document_.

      <?xml version="1.0"?>
      <!DOCTYPE script SYSTEM "http://example.org/script.dtd">
    - <script>
      - <episode>
         <title> The Witch </title>
        </episode>
      + <act>
      + <act>
      - <act id="a3">
        + <scene>
        - <scene>
           <line character="Buffy"> Twisted. </line>
          </scene>
        </act>
      </fun>

While that is shown, we have to listen for mutation events to switch out of the
source view if any of the conditions listed above stop applying (e.g., a
stylesheet PI is added to the document). If the user clicks the "original
unstyled document" link then we'll just switch to our of source view straight
away. Viewing the source of this tree should show the original document's
source, not the source of the script that generated the view. Accessing the DOM
of the frame should access the real document's DOM, not the source view's DOM.
The DOM inspector should see the original document, not the source view either.

We should avoid:
 * Breaking XHTML, MathML, XUL, and SVG.
 * Making it hard to add extensions to ua.css without rebuilding.
 * Killing dead the potential for DOM-based creation of styled XML documents.

Notes:
[1] There are various ways to add author stylesheets: style attributes in
various namespaces, style elements in various namespaces, various different link
elements in various namespaces, HTTP headers, presentational attributes on
elements in certain namespaces, etc. I don't know how to test for this properly.
For example, one way to add styles is to dynamically bind the root element to an
XBL binding that links to a CSS stylesheet. We have to be able to cope with this
case correctly.

[2] Similarly, scripts can be added in many different ways. The XBL case is
possible here too, but that's not the only way. Adding event handlers via the
DOM is another possibility. Some elements and attributes in various namespaces
add script to the document, etc.

[3] The contents of the ua.css file can change depending on the build options
and user modifications at run time. For example, MathML is sometimes supported
and sometimes not, and all links (XLink included) are styled by html.css. So
again we can't hardcode this. The best solution I can think of is suboptimal and
is to check the CSSOM of the UA stylesheet and its kids when displaying the XML
file in question. The ideal solution would be to crawl the DOM checking
getComputedStyle to find out if anything was styled, but that's just stupid from
a performance point of view.
Whiteboard: [Hixie-P4][ADT3] see comment 37 → [Hixie-P4][ADT3] see comment 113

    
    

    
  
Hixie: as far as performance worries... I'll be happy so long as it renders
faster than I can complete these steps:

  1. try to view xml in mozilla.
  2. curse that mozilla still just spits a bunch of unuseable text at me.
  3. click on view source and curse some more because the xml document isn't
     formatted pretty and the actually source is also unuseable.
  4. start up IE.
  5. notice that i need to apply the latest security fixes for IE.
  6. reboot.
  7. start up IE.
  8. try to view xml in IE.
  9. curse that I had to start up IE, but at least now I can read the xml
     output.

So if you can make it faster than the above, I will be a happy camper.

    
    

    
  
I agree with comment #113 in thay displaying the tree view by default is a much
better thiing to do!

But, how would the other views open? a popup? same window?
Why not using a tabbed view:
     ___________    ______________________   _____________________________   
    / Tree view \  / Inspect DOM structure \/ unstyled (useless =) ) view \
+---           --------------------------------------------------------------+
|  -<library>                                                                |
|   +<book>
|   +<book>

I think it would be nice because these are all alternate, equally valid, ways of
displaying the document. And reusing the tab metaphor will make the use of this
 more instantly evident (no need of buttons with explanations).

Anyway, it's just an idea..

    
    

    
  
The proposal in comment #113 is sufficient. But what I would really like to see
is that everything that can be rendered (such as MathML or XHTML) is rendered,
and everything that can not be rendered (such as plain namespace-less XML) is
shown in the collapsable tree form. The rendered stuff can be shown within the tree.

If this is too much work or just not possible, I am still quite happy with #113.

I also like the tab idea. To avoid confusion though, these tabs should be
clearly distinct from the regular tabs.


    
    

    
  
If there is any styled content in the document (e.g. any MathML or XHTML
content) then it will be rendered in the styled view, not in the tree view.

As for the tabs idea: The DOM Inspector view would be in the sidebar or in its
own window, as now; the view source view would be in its own window, as now;
that leaves merely the unstyled view and the IE-like tree view. Since the
unstyled view is "useless" as you put it, we don't really need to go to the
lengths of adding tabs or anything. IMHO.

    
    

    
  
I find comment #113 sufficient and am happy with that approach. The suggestion 
of a special tabbed view (with its own tabset distinct from the main tabs) in 
comment #116 is even better IMO and if the #113 approach is taken would be a 
splendid RFE for the next milestone.

However, I vigorously oppose the idea of rendering "islands" of MathML, XHTML, 
SVG and so forth that are encountered inline within an otherwise raw tree-view 
of XML by default. I don't think it's genuinely useful for the XML-tree's 
audience, who are presumably looking at XML to dissect, spot-check or debug it.

Rendering a MathML or SVG or RSS or whatever *document* in some useful way 
would be great in cases where a default transformation would be more useful to 
more people than the tree view would be. Just as NS4 rendered vCards as 
readable business cards, rendering a raw MathML document as math would be 
splendid, as would rendering RSS in, say, a tabular format with hyperlinks, or 
rendering a standards-based feed of TV listings in a pretty grid if a good 
stylesheet were available for the doctype. Obviously the latter isn't something 
that anyone's expected to tackle now, but I think we'd do well to start 
thinking of this as a natural path to take.

As for rendering "islands" of MathML and SVG and XHTML and such that are 
contained in an otherwise tree-dumped raw XML file, maybe an apporpriate 
behavior to aim for down the road would be to mark such "renderable" islands in 
the tree view and allow them to be rendered when clicked via a context menu.

    
    

    
  
Steve: but Mozilla already renders MathML and SVG "islands" when encountered in 
XHTML, so how should it "know" about when to render and when to display as a 
tree? I think that would be difficult (and questionable maybe) to implement 
such an asymetrical system. Up to now we had been discussing that we want to 
see an XML tree when other ways of displaying were not defined. But there are 
several XML "dialects" that have a very clear function as a display/layout 
language, so personally I think that XHTML, MathML and SVG should be rendered 
whenever possible.

What you want should really be handled by View Source (if a pretty printer 
option would be added to the View Source it would be usefull for any kind of 
XML).

    
    

    
  
Okay, FWIW (which isn't much) I drop my objection to rendering islands of 
MathML and such as long as it's pleasant and prints nicely :)

Being able to get pretty-printed XML source and the raw view of source exactly 
as it came from the server are both equally important and serve different 
purposes.  Hopefully both will be readily available at all times.

    
    

    
  
The problem with rendering these "recognized XML islands" is that when that kind
of mixed XML is found, you can't be sure about the senantic result. E.g. an XSLT
stylesheet would have XHTML embedded, but it would be a broken XHTML (e.g.
intended attributes would have been supplied through <xsl:attribute>).
One solution is to style the XML document only if either:
a) there is a recognized styling PI.
b) we know the namespace of the *root element*.

So that Mozilla would style: <html:html><html:b>Hi mom</html:b></html:html>, but
won't style <x:myTag><html:html><html:b>Hi mom</html:b></html:html></x:myTag>.


    
    

    
  
Quoting from the spec (comment 113):

| If an XML document has no author stylesheet [1] no author script [2] and
| contains no elements or attributes in namespaces given in ua.css [3], then we
| would display the following in the content area: [...]

    
    

    
  
But what would that mean for a document like this:

<foo xmlns="urn:MyFirstNamespace">
   <bar>
      <math xmlns="http://www.w3.org/1998/Math/MathML">
         ...
      </math>
   </bar>
</foo>

Would it try to render the MathML? But what would it do with the rest?
The remark made by Nicolas in #122 does seem to have some merit doesn't it?
(The fact that the root element would be the deciding factor.)
This could mean that MathML inside XHTML would be rendered but that MathML 
inside the above example would depend on the stylesheet defined for <foo>.

This would also mean that a stylesheet designed to show unknown or vanilla XML 
as a tree would not render XHTML, MathML or SVG but would show the XML in the 
tree instead. But you could make a tree-stylesheet that does support XHTML, 
MathML and/or SVG by including the respective stylesheets, couldn't you?

    
    

    
  
An example:

Suppose you have a big XML file, representing a library. Lots of <book>s with
their ISBNs, prices and descriptions. This kind of custom, pure data XML file is
the one being targeted with this RFE. Some developer will load this file in
Mozilla in order to inspect it, in order to check it for well-formedness.

Now suppose somebody adds to the <description> tag some <html:strong>words
</html:strong></description>. Then, the whole file would be rendered as a
useless bunch of flowed text. It doesn't sound right to me.


    
    

    
  
We're not doing this so that users have a way of viewing all XML files. There
already are plenty of XML viewers out there. We're only doing this so that users
don't think we don't support XML. If the page has some styling, then that's
fine, it'll look like we're styling it.

Keying off the root namespace is dodgy, because it's possible that everything
but the root namespace will have style information, and we wouldn't want to
_not_ style that.

For example:

   <composite xmlns="urn:net.example.namespace">
    <html xmlns="...">
      ...
      <script ...>
       ... something which uses the SVG image below ...
      </script>
      ...
    </html>
    <svg id="image1" style="display: none">
     ...
    </svg>
   </composite>

    
    

    
  
(in reply to #126)

does your example have well-defined semantics for styling (I doubt it), if not 
it should be rendered as a tree.

otoh, just halfassedly supporting some feature to prove you're not **** isn't 
an excuse. if you're not going to support it, say so and apollogise, but if you 
are, do it, and do it well.

    
    

    
  
(in reply to #126)

I have to agree with the remark made by spongman in #127 which is the same 
point I made in #124: there is no good way to render such a composite document 
so the best way would probably be to look to the root namespace and make your 
decisions based on that. This would not break any support for existing 
documents (like XHTML, MathML and SVG) while having the advantage that it is 
probably very easy to implement.

Like I said in #124 you can always make a stylesheet for the root namespace and 
include the ones for XHTML and SVG if you want to make your example work 
(another plus for making it possible to define custom namespace-stylesheet 
mappings =).

This would maybe also fix any difficult problems related to scripting code 
changing all kinds of things and making life generally more difficult: if 
rendering of XHTML, MathML and SVG is undefined for a document whose root 
namespace is unknown then the "rendering" of script (read: execution of script) 
might be undefined as well! This means that maybe you don't have to worry about 
scripting in unknown document formats? Just a thought.


    
    

    
  
All these things _are_ defined. There isn't anything undefined about the example
document I posted above. Even the semantics are reasonably well defined, since
there is only one element in the root namespace, and it doesn't represent
anything except a way to hold many different documents together.
Alias: xmlview

    
    

    
  
#129: I think we should at least agree that Mozilla is a web browser, an (X)
HTML viewer if you like. All other stuff is extra. So now you're telling us 
that the (X)HTML standard says that you can use <composite 
xmlns="urn:net.example.namespace"> tags to aggregate several XML documents and 
that a browser should be able to understand this?

Can you tell me how it should be rendered? Where are the documents that tell me 
how browsers should handle and render composites?

And even so you could easily add "urn:net.example.namespace" as one of the root 
elemements that Mozilla understands and make a stylesheet that includes the 
support for the other sub documents that you want rendered inside these 
composites.

    
    

    
  
Here's an example of the kind of document I mean:
   http://www.hixie.ch/tests/evil/xml/011.xml
This document is currently rendered exactly per the CSS spec. The way we render
that Web document (or any of the others in that directory) should not change
when we fix this bug.

Mozilla is indeed a Web browser, specifically it is a CSS renderer, with default
rules for XHTML, MathML and XUL, and some special C++-level support for MathML,
XBL, SVG and XHTML form controls.

    
    

    
  
ad. #131: Ok, I understand that this would mean that Mozilla _should_ actually 
do the "rendering islands" stuff (especially because that's what it does 
already) but that still leaves the fact that for Mozilla the <composite> 
document namespace is an unknown quantity which it does not know how to render.

If we are ever going to get XML tree viewing in Mozilla implemented as 
suggested in this RFE this would then mean that the <composite> document above 
would render as a tree with 2 leaves: one showing HTML and the other showing an 
SVG image.

If that is the way it's going to be fine although that is exactly the way IE 
renders it and XHTML embedded into other documents can look pretty horrible.

PS: How would any scripting included in the embedded XHTML document be handled? 
I would think it was bound to fail because it will never expect that the XHTML 
it is in is not actually the root of the document.

    
    

    
  
> the <composite> document namespace is an unknown quantity which it does not
> know how to render.

No, it's not -- it's an element, and CSS specifies how to render *every* element
-- not just those with rules that match them. (For example, '<composite>' has
'display:inline'.) That's how we know how to render it _now_.


> If we are ever going to get XML tree viewing in Mozilla implemented as
> suggested in this RFE this would then mean that the <composite> document above
> would render as a tree with 2 leaves: one showing HTML and the other showing
> an SVG image.

Only if the implementation doesn't follow what I specified in comment 113.
According to the spec I am proposing, we would render that as we do now, because
it contains known namespaces. That is, im my opinion, correct.


> How would any scripting included in the embedded XHTML document be handled? I
> would think it was bound to fail because it will never expect that the XHTML
> it is in is not actually the root of the document.

Any script or style or known namespace should trigger the (un)styled view (i.e.
not the tree view), so there would be no problem.

    
    

    
  
Jonas is working on this.
Assignee: nisheeth → sicking
Status: ASSIGNED → NEW
Keywords: nsbeta1- → nsbeta1+
Target Milestone: mozilla1.0 → mozilla1.2alpha

    
    

    
  


  
This is just attaching what i've got so far so that we don't loose it. Most of
this is making sure not *all* processing instructions implement
nsIStyleSheetLinkingElement. This will also save us some memory/cycles when
using PIs other then xml-stylesheet

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Prettyprinting stage 1 (obsolete)
        — 
          — Splinter Review
      

    


  
This is a working implementation of prettyprinting stage one. This mostly
includes detecting when prettyprinting should be done. For now it displays the
prettyprinting by transforming the DOM so the preference defaults to off.

I'd like to get this checked into the tree as a basis for the continued work

        Attachment #34133 -
        Attachment is obsolete: true

        Attachment #40345 -
        Attachment is obsolete: true

        Attachment #94379 -
        Attachment is obsolete: true

    
    

    
  
Oh, and for now I have a .bmp as image. This should of course not be the case
once we check in, but i don't have any other tools on my computer

    
    

    
  
After a quick look at the new PI code I could not see the following case being 
covered.

<?something?> changed using dom to <?xml-stylesheet ...?>

    
    

    
  
I'm not entierly sure what you mean, but the current patch does not handle the
DOM being accessed after prettyprinting is done, which is why it is turned off
by default. It is however the basis for continued work

    
    

    
  
What the patch does:

Most changes should be very strait forward, just unsets the mPrettyPrintXML
boolean in a buch of places and then call a XSLT stylesheet if the bool is still
on after reading the entire document.

The two real changes I had to do was to make sure that not all
ProcessingInstructions implement nsIStyleSheetLinkingElement (which was a good
thing to do anyway IMHO) and to implement the HasRegisteredFactory function on
the nsNameSpaceManager. To implement HasRegisteredFactory I made us use one and
the same element factory for all non-registered namespaces instead of creating a
new default one for every namespace.
Status: NEW → ASSIGNED

    
    

    
  
Erik: ooh, now i understand what you're asking. The target of processing
instruction are readonly so you can't change a <?foo?> into a <?xml-stylesheet?>

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Prettyprinting stage 1 v2 (obsolete)
        — 
          — Splinter Review
      

    


  
forgot to diff mozilla/dom

        Attachment #95231 -
        Attachment is obsolete: true

    
    

    
  
>+NS_IMETHODIMP
>+NameSpaceManagerImpl::HasRegisteredFactory(PRInt32 aNameSpaceID,
>+                                           PRBool* aHasFactory)
>+{
>+  nsCOMPtr<nsIElementFactory> ef;
>+  GetElementFactory(aNameSpaceID, getter_AddRefs(ef));
>+  *aHasFactory = ef != gDefaultElementFactory;
>   return NS_OK;
> }

You might want to check for gDefaultElementFactory != nsnull. Probably very
unlikely, so up to you.

>Index: content/xml/document/resources/XMLPrettyPrint.css
>===================================================================
>RCS file: content/xml/document/resources/XMLPrettyPrint.css
>diff -N content/xml/document/resources/XMLPrettyPrint.css
>--- /dev/null	1 Jan 1970 00:00:00 -0000
>+++ content/xml/document/resources/XMLPrettyPrint.css	22 Aug 2002 09:40:57 -0000
>@@ -0,0 +1,82 @@

Need a license?

>Index: content/xml/document/resources/XMLPrettyPrint.xsl
>===================================================================
>RCS file: content/xml/document/resources/XMLPrettyPrint.xsl
>diff -N content/xml/document/resources/XMLPrettyPrint.xsl
>--- /dev/null	1 Jan 1970 00:00:00 -0000
>+++ content/xml/document/resources/XMLPrettyPrint.xsl	22 Aug 2002 09:40:57 -0000
>@@ -0,0 +1,140 @@
>+<?xml version="1.0"?>
>+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
>+
>+  <xsl:template match="/">
>+    <html>

Do we want this to be XHTML? If so, set the namespace, if not you should set
<xsl:output method="html" />

>+PRBool
>+nsXMLContentSink::ShouldPrettyPrint()
>+{
>+  if (!mPrettyPrintXML || (mPrettyPrintHasFactoredElements &&
>+                           !mPrettyPrintHasSpecialRoot)) {
>+    mPrettyPrintXML = PR_FALSE;
>+
>+    return PR_FALSE;
>+  }
>+
>+  // Check for correct load-command or if we're in a display:none iframe
>+  nsString command;
>+  mParser->GetCommand(command);
>+  if (!command.Equals(NS_LITERAL_STRING("view")) ||
>+      !mDocument->GetNumberOfShells()) {
>+    mPrettyPrintXML = PR_FALSE;
>+
>+    return PR_FALSE;
>+  }
>+
>+  // check if we're in an invisible iframe
>+  nsCOMPtr<nsIScriptGlobalObject> sgo;
>+  mDocument->GetScriptGlobalObject(getter_AddRefs(sgo));
>+  nsCOMPtr<nsIDOMWindowInternal> internalWin = do_QueryInterface(sgo);
>+  nsCOMPtr<nsIDOMElement> frameElem;
>+  if (internalWin) {
>+      internalWin->GetFrameElement(getter_AddRefs(frameElem));
>+  }
>+
>+  if (frameElem) {
>+    nsCOMPtr<nsIDOMCSSStyleDeclaration> computedStyle;
>+    nsCOMPtr<nsIDOMDocument> frameOwnerDoc;
>+    frameElem->GetOwnerDocument(getter_AddRefs(frameOwnerDoc));
>+    nsCOMPtr<nsIDOMDocumentView> docView = do_QueryInterface(frameOwnerDoc);
>+    if (docView) {
>+      nsCOMPtr<nsIDOMAbstractView> defaultView;
>+      docView->GetDefaultView(getter_AddRefs(defaultView));
>+      nsCOMPtr<nsIDOMViewCSS> defaultCSSView = do_QueryInterface(defaultView);
>+      if (defaultCSSView) {
>+        defaultCSSView->GetComputedStyle(frameElem, NS_LITERAL_STRING(""),
>+                                         getter_AddRefs(computedStyle));
>+      }
>+    }
>+
>+    if (computedStyle) {
>+      nsAutoString visibility;
>+      computedStyle->GetPropertyValue(NS_LITERAL_STRING("visibility"),
visibility);
>+      if (!visibility.Equals(NS_LITERAL_STRING("visible"))) {
>+        mPrettyPrintXML = PR_FALSE;
>+
>+        return PR_FALSE;
>+      }
>+    }
>+  }
>+  
>+  // check the pref
>+  nsCOMPtr<nsIPref> prefs = do_GetService(NS_PREF_CONTRACTID);
>+  if (prefs) {
>+    PRBool pref = PR_FALSE;
>+    prefs->GetBoolPref("layout.xml.prettyprint", &pref);
>+    if (!pref) {
>+      mPrettyPrintXML = PR_FALSE;
>+
>+      return PR_FALSE;
>+    }
>+  }

Should we check the pref first before doing all these other checks?

>+
>+  return PR_TRUE;
>+}
>+
>+
> NS_IMETHODIMP
> nsXMLContentSink::DidBuildModel(PRInt32 aQualityLevel)
> {
>+  nsresult rv = NS_OK;
>+
>   // XXX this is silly; who cares?
>   PRInt32 i, ns = mDocument->GetNumberOfShells();
>   for (i = 0; i < ns; i++) {
>@@ -359,7 +445,16 @@
> 
>   mDocument->SetRootContent(mDocElement);
> 
>-  nsresult rv = NS_OK;
>+  // Check if we want to prettyprint
>+  if (ShouldPrettyPrint()) {
>+    NS_ASSERTION(!mXSLTransformMediator, "Prettyprinting an XSLT styled
document");
>+
>+    nsCOMPtr<nsIURI> uri;
>+    rv = NS_NewURI(getter_AddRefs(uri),
NS_LITERAL_STRING("resource:///res/xml/XMLPrettyPrint.xsl"));

Make this
    rv = NS_NewURI(getter_AddRefs(uri),
                   NS_LITERAL_STRING("resource:///res/xml/XMLPrettyPrint.xsl"));


>+  // If we care, find out if we just used a special factory.
>+  if (!mPrettyPrintHasFactoredElements && !mPrettyPrintHasSpecialRoot &&
>+      mPrettyPrintXML) {
>+    
>+    PRBool hasFactory = PR_TRUE;
>+    gNameSpaceManager->HasRegisteredFactory(aNameSpaceID, &hasFactory);
>+    
>+    if (hasFactory) {
>+      mPrettyPrintHasFactoredElements = PR_TRUE;
>+    }
>+  }

Can't you just do 

  if (!mPrettyPrintHasFactoredElements && !mPrettyPrintHasSpecialRoot &&
      mPrettyPrintXML) {
    gNameSpaceManager->HasRegisteredFactory(aNameSpaceID,
                                            &mPrettyPrintHasFactoredElements);
  }


>@@ -1647,6 +1754,17 @@
>     if (NS_OK == result) {
>       // If this is the document element
>       if (!mDocElement) {
>+        
>+        // check for root elements that needs special handling for
>+        // prettyprinting
>+        if ((nameSpaceID == kNameSpaceID_XBL &&
>+             tagAtom == nsXBLAtoms::bindings) ||
>+            (nameSpaceID == kNameSpaceID_XSLT &&
>+             (tagAtom == nsLayoutAtoms::stylesheet ||
>+              tagAtom == nsLayoutAtoms::transform))) {
>+          mPrettyPrintHasSpecialRoot = PR_TRUE;
>+        }
>+

Not sure if we should think about making this extensible?

>Index: build/mac/build_scripts/MozillaBuildList.pm
>===================================================================
>RCS file: /cvsroot/mozilla/build/mac/build_scripts/MozillaBuildList.pm,v
>retrieving revision 1.228
>diff -u -r1.228 MozillaBuildList.pm
>--- build/mac/build_scripts/MozillaBuildList.pm	13 Aug 2002 11:02:29 -0000	1.228
>+++ build/mac/build_scripts/MozillaBuildList.pm	22 Aug 2002 09:40:58 -0000
>@@ -238,6 +238,9 @@
>     my($html_dir) = "$resource_dir" . "html:";
>     InstallResources(":mozilla:layout:html:base:src:MANIFEST_RES",           
         "$html_dir");
> 
>+    my($xml_dir) = "$resource_dir" . "xml:";
>+    InstallResources(":mozilla:content:xml:document:resources:MANIFEST_RES",
"$xml_dir");

Align "$xml_dir" with "$htmldir"

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Prettyprinting stage 1 v3 (obsolete)
        — 
          — Splinter Review
      

    


  
Couldn't fully change the HasRegisteredFactory-call since
mPrettyPrintHasFactoredElements isn't a PRBool, made it somewhat neater though.


didn't move the pref-code up since once this bug is fully fixed we will default

to the pref on and we should on most systems never fail the pref-check. So
better do it after checks that might actually fail.

Kept the output-method to html to avoid running into bug 158457

        Attachment #96290 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 97166 [details] [diff] [review]
Prettyprinting stage 1 v3

+class nsXMLStylesheetPI : public nsXMLProcessingInstruction,
+			   public nsStyleLinkElement
+{
+public:
+  nsXMLStylesheetPI(const nsAString& aData);
+  ~nsXMLStylesheetPI();

This dtor must be virtual.

- In nsXMLContentSink::ShouldPrettyPrint():

+  // Check for correct load-command or if we're in a display:none iframe
+  nsString command;
+  mParser->GetCommand(command);
+  if (!command.Equals(NS_LITERAL_STRING("view")) ||
+      !mDocument->GetNumberOfShells()) {
...

|command| should be an nsAutoString here to avoid an unnecessary string copy.

...
+  if (internalWin) {
+      internalWin->GetFrameElement(getter_AddRefs(frameElem));
+  }

2-space indentation here please :-)

sr=jst

        Attachment #97166 -
        Flags: superreview+

    
    

    
  
Does this patch pass (i.e. act exactly the same as on the trunk now) all the
regression tests at http://www.hixie.ch/tests/evil/xml/ ?

    
    

    
  
Yes, since it's disabled by default :-)

Seriously, for now it won't which is why it's disabled by default. Once stage
two is done it should pass all tests and it'll be enabled by default. 

    
    

    
  
Okie dokie.

    
    

    
  
Comment on attachment 97166 [details] [diff] [review]
Prettyprinting stage 1 v3

this one has landed

        Attachment #97166 -
        Attachment is obsolete: true

    
    

    
  
Comment#149 says it's landed. Does that mean it will be start appearing in
nightly trunk builds, or does one need to build mozilla themself in order to see it?

P.S. I'm on Mac OS X.1


    
    

    
  
sorry, i forgot to write a real comment.

Stage one of this has landed. That means that it is working in the nightlies but
it is disabled by default since it breaks some legal (although rare) ways of
loading XML. Note that this gets us on par with IE.

To enable the feature add the following line to prefs.js:

user_pref("layout.xml.prettyprint", true);


    
    

    
  
And I guess this means distributors will flip the switch, with all that that
entails? :-(

Any ETA on the second part? Please say soon...

    
    

    
  
soon :)

This should be fully done by at least moz1.2
Target Milestone: mozilla1.2alpha → mozilla1.2beta

    
    

    
  
That's encouraging. Now come on, chop chop. ;-)

    
    

    
  
So how do I see the patch in action? I added the pref (in today's nightly) and
went to the URL mentioned <http://p.moreover.com/cgi-local/page?index_xml+xml>
but I still didn't see a pretty print layout. What am I doing wrong?

    
    

    
  
Tried this out and it worked fine. Some urls that you might find handy for testing:
http://www.w3.org/Math/characters/entities.xsl
http://www.w3.org/Math/characters/characters.xsl (long...)
http://www.w3.org/Math/characters/unicode.xml (long...)
URL: http://www.w3.org/Math/characters/ent...

    
    

    
  
BTW, it might be best to style comments with  "white-space: pre", as IE does.

    
  
Blocks: majorbugs

    
    

    
  
Doesn't work for me in the latest build- the XSL/CSS/BMP weren't installed.  I
dumped my own XSL file in there (based on the attachment in this bug) and it
worked fine with the pref on.

    
    

    
  
*** Bug 167558 has been marked as a duplicate of this bug. ***

    
    

    
  
You should not pretty print if there is an XML parsing error.

    
    

    
  
The resource files need to be added to the packaging lists for installers. This
is the reason why people who download nightlies can't get this to work at the
moment.

    
    

    
  
ugh, i just noticed havn't been getting bugmail for the last few days (thought
it just was a slow weekend). This only works for people building on their own.
I'm on it.

    
    

    
  
Comment on attachment 98666 [details] [diff] [review]
packager changes. Doesn't include embedding yet

jst says sr=jst

        Attachment #98666 -
        Flags: superreview+

    
    

    
  
It would be nice if the header had a couple of buttons, "view source" and
"inspect DOM" (the latter is a bit redundant but it would help people discover
the DOM inspector, which IMHO is the coolest thing ever)

    
    

    
  
Suggestion: The color used for .elemname in XMLPrettyPrint.css is "red" which is
fairly bright and distracting.  "maroon" is easier on the eyes (good reason) and
is appears closer to IE (soso reason).

IE also displays the XML prologue (<?XML version...)...

The .markup section in the css doesn't have a semi after color: blue

This change is great!  I can now use Mozilla for the xml development I do.  Thanks.

    
    

    
  
I notice that namespace nodes don't appear. E.g., if I look at an XSL
stylesheet, the first node appears like this:

  <xsl:stylesheet version="1.0">

The original document of course looks like:

  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

BTW IE displays the namespaces correctly.


    
    

    
  
It doesn't seem to work on:
   http://www.hixie.ch/tests/evil/xml/002b.xml
(Ignore for now that that file is a part of a test in which the file _shouldn't_
trigger this XML view -- the point is that on its own, the file _should_ get the
interactive XML view and it isn't for some reason.)

    
    

    
  
Thanks for getting this great feature into 1.2a!

There might be some issues with the colors though. The attribute names seem to
be displayed using a somewhat "pink" color, and that may be a little **** the
eyes. Additionally, if Mozilla's used for presentations with a projector (such
as what people do with Powerpoint), the colors may not be seen too well from
"the back of the room." I think we need colors that contrast better with the
white background.

Ideally, the user should be able to set the colors from the Preferences dialog.
I don't know much about the internals about how this is currently implemented.
Is this possible?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        stage 2 (obsolete)
        — 
          — Splinter Review
      

    


  
This implements stage two, prettyprinting using a binding.

The only thing missing until we're fully done is dropping the binding when
needed.

I've moved the .xml/.xsl/.css files to xpfe/components which is nicer since
they'll get packed and it means that no changes are needed to packaging (the
patch backs out attachment 98666 [details] [diff] [review])

        Attachment #31658 -
        Attachment is obsolete: true

        Attachment #36108 -
        Attachment is obsolete: true

        Attachment #36257 -
        Attachment is obsolete: true

        Attachment #98666 -
        Attachment is obsolete: true

    
    

    
  
+ * Version: NPL 1.1/GPL 2.0/LGPL 2.1
New NPL code isn't being allowed into the tree, last I checked.

As this affects XBL loading, does it affect Txul or Ts?

I take it this doesn't yet handle the many cases described in comment 113?

    
    

    
  
Comment on attachment 101676 [details] [diff] [review]
stage 2

I don't like the move. This should work in the embedding case, and if you move
them to xpfe they won't get into embedding applications, I think. Also they
should logically be "close" to the source that uses them. Finally packaging
them means it becomes very difficult for the users to change the stylesheets.

        Attachment #101676 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        prettyprint stage 2 (obsolete)
        — 
          — Splinter Review
      

    


  
ok, this is the same as the previous one except that i've move the xbl/xslt/css
files back to content/xml/document/resources

The syncloader is pretty much copied from transformiix, and then rearranged to
be able to load local documents without the overhead of createing a new
eventqueue. I've also created a service out of it by wrapping a class around
the nsSyncLoader class.

    
    

    
  
Comment on attachment 102254 [details] [diff] [review]
prettyprint stage 2

>Index: content/base/public/nsISyncLoadService.idl

>+interface nsISyncLoadService : nsISupports

the name for this interface is too generic.  please pick something more
specific to nsIDOMDocument loading.

>+{
>+    /**
>+     * Synchronously load the document specified in documentURI.
>+     *
>+     * @param documentURI The URI of the document to load.
>+     * @param aLoader The document that is trying to load this document.
>+     *
>+     * @returns The document loaded from the URI.
>+     */
>+    nsIDOMDocument loadDocument(in nsIURI documentURI, in nsIURI loaderURI,
>+                                in nsILoadGroup loadGroup);
>+    
>+    nsIDOMDocument loadLocalDocument(in nsIURI documentURI,
>+                                     in nsIURI loaderURI,
>+                                     in nsILoadGroup loadGroup);
>+
>+    nsIDOMDocument loadLocalXBLDocument(in nsIURI uri,
>+                                        in nsILoadGroup loadGroup);
>+};

please document all of these methods completely.  use "a" prefixes on
all variable names.  also if there are any special exception codes, you
should be sure to document those as well.

also, it might be good to make the input be a channel, since that would
give consumers more flexibility.  i.e., suppose a consumer wanted to add
a special HTTP header or suppose they wanted to issue a POST request.
this interface would not allow for such options.

also, i think you should add a very very large warning to the top of this
interface definition.  something like this:


/*************************************************************************
 *									 *
 *			    **** NOTICE ****				 *
 *									 *
 *    nsISyncLoadService defines synchronous methods to download	 *
 *    data from the network.  Any delays from the server will		 *
 *    appear as a hang in the mozilla UI.  Therefore, this interface	 *
 *    should be avoided as much as possible.				 *
 *									 *
 *    Don't make me come over there!!					 *
 *									 *
 *									 *
 ************************************************************************/

>+
>+%{ C++
>+#define NS_SYNCLOADSERVICE_CID                      \
>+ { /* 0e4e7d00-f71a-439f-9178-1a71ff11b55f */       \
>+  0x0e4e7d00, 0xf71a, 0x439f,                       \
>+ {0x91, 0x78, 0x1a, 0x71, 0xff, 0x11, 0xb5, 0x5f} }
>+#define NS_SYNCLOADSERVICE_CONTRACTID               \
>+"@mozilla.org/content/syncload-service;1"
>+%}

CIDs and ContractIDs do not belong in a IDL file.  The rule is
that each module file should define a header file to contain all
of its component/service CIDs and ContractIDs.	see for example
nsNetCID.h or nsXPCOMCID.h.  please follow this convention.  if
not now, then in the future at least.


>Index: content/base/src/nsSyncLoadService.cpp

>+// This is ugly, but nsXBLContentSink.h isn't exported
>+extern
>+nsresult
>+NS_NewXBLContentSink(nsIXMLContentSink** aResult,
>+                     nsIDocument* aDoc,
>+                     nsIURI* aURL,
>+                     nsIWebShell* aWebShell);

how about a comment in nsXBLContentSink.h mentioning this
dependency.  future developers will thank you ;-)


>+nsSyncLoader::PushSyncStream(nsIStreamListener* aListener)
...
>+    aListener->OnStartRequest(mChannel, nsnull);

this recursive callback is ok/desired, right?

>+        rv = aListener->OnDataAvailable(mChannel, nsnull, bufferedStream,
>+                                        sourceOffset, readCount);
>+        if (NS_FAILED(rv)) {
>+            break;
...
>+    }
>+    aListener->OnStopRequest(mChannel, nsnull, NS_OK);

why not "OnStopRequest(mChannel, nsnull, rv);" ???


>+    // Set up buffering stream
>+    nsCOMPtr<nsIInputStream> bufferedStream;
>+    rv = NS_NewBufferedInputStream(getter_AddRefs(bufferedStream),
>+                                   in, 4096);
>+    NS_ENSURE_SUCCESS(rv, rv);
>+
>+    // Load
>+    listener->OnStartRequest(channel, nsnull);
>+    PRUint32 sourceOffset = 0;
>+    while (1) {
>+        PRUint32 readCount = 0;
>+        rv = bufferedStream->Available(&readCount);
>+        if (NS_FAILED(rv) || !readCount) {
>+            break;
>+        }
>+
>+        rv = listener->OnDataAvailable(channel, nsnull, bufferedStream,
>+                                       sourceOffset, readCount);
>+        if (NS_FAILED(rv)) {
>+            break;
>+        }
>+
>+        sourceOffset += readCount;
>+    }
>+    listener->OnStopRequest(channel, nsnull, NS_OK);

looks like code duplication here.  how about pulling this out into
a static helper function at least?


>+nsresult NS_NewSyncLoadService(nsISyncLoadService**);

does this belong in a header file somewhere?


>Index: content/xbl/src/nsXBLService.cpp

>+  nsCOMPtr<nsIDOMDocument> domDoc;
>+  nsCOMPtr<nsISyncLoadService> loader =
>+    do_GetService("@mozilla.org/content/syncload-service;1");
>+  nsresult rv = loader->LoadLocalDocument(aURI, nsnull, nsnull, getter_AddRefs(domDoc));
>+  if (rv == NS_ERROR_FILE_NOT_FOUND) {
>+      return NS_OK;

would XBL benefit from caching a reference to the sync loader service?


>Index: content/xml/document/src/nsXMLContentSink.cpp

>+  rv = NS_NewURI(getter_AddRefs(xslUri),
>+                 NS_LITERAL_STRING("chrome://communicator/content/xml/xmlPrettyPrint.xsl"));

use NS_LITERAL_CSTRING here instead to avoid a runtime conversion.

    
    

    
  
Comment on attachment 102254 [details] [diff] [review]
prettyprint stage 2

In nsSyncLoader::LoadDocument you are losing the rv from StartDocumentLoad(). 
NS_ENSURE_SUCCESS(rv, rv)

Would be nice to have a Load() method that took in the target document and
content sink (in addition to the channel, as Darin proposed).  That should
handle the shared code for the XBL implementation.

This is just criminal, PLEASE make a topic :)
+  return binding->Observe(resultDocument, "", NS_LITERAL_STRING("").get());

r=jkeiser with that though I'd like to see the SyncLoad changes if you make
them (given the time constraints I personally am OK with it if you do the
SyncLoad change in a separate patch but do it soon)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        prettyprint stage 2 v2 (obsolete)
        — 
          — Splinter Review
      

    


  
addresses jkeisers and darins comments. I went with darins suggestion for how
to reuse the code that pushes a stream into a listener since IMHO that gave
cleanest code and resulted in pretty much no codeduplication

        Attachment #102254 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 102307 [details] [diff] [review]
prettyprint stage 2 v2

sr=darin

        Attachment #102307 -
        Flags: superreview+

    
    

    
  
Comment on attachment 102307 [details] [diff] [review]
prettyprint stage 2 v2

r=jkeiser

        Attachment #102307 -
        Flags: review+

    
    

    
  
Comment on attachment 102307 [details] [diff] [review]
prettyprint stage 2 v2

checked in

        Attachment #102307 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 102307 [details] [diff] [review]
prettyprint stage 2 v2

>+  if (par.parentNode.className == 'expander-closed') {
>+    par.parentNode.className = '';
>+    event.originalTarget.src = 'chrome://global/skin/tree/twisty-open.gif';
>+  }
>+  else {
>+    par.parentNode.className = 'expander-closed';
>+    event.originalTarget.src = 'chrome://global/skin/tree/twisty-clsd.gif';
>+  }

>+    <td class="expander"><img src="chrome://global/skin/tree/twisty-open.gif"/><div class="spacer"/></td>

So, third-party themes will have to specify these exact images?

Also, where's the white-space: pre; for CDATA like rbs requested?

    
    

    
  
CDATA has no different meaning from textnodes so I won't style them any
differently. Good point about making the twisties skinnable though, i'll look
into what needs to be done for that

    
    

    
  
so what's left to do here? only do the themability and the all.js change, or is
there more?

    
    

    
  
before everybody yells that no all.js change is needed i'm going to say that no
all.js change will occur, i'll just default the code the other way around (or
remove the pref entierly)

what is left is that i need to drop the binding if the document is mutated

    
    

    
  
> > Also, where's the white-space: pre; for CDATA like rbs requested?
>
> CDATA has no different meaning from textnodes so I won't style them any
> differently.

neil had a noble intention, but he misquoted me. What I said was to style
comments as pre. Visit http://www.w3.org/Math/characters/entities.xsl with IE
and Mozilla to see the difference. In Mozilla, comments (top of the page) are
wrapped in a messy way, whereas they appear neat and tidy in IE.

    
    

    
  
Personally I think I like how they look in Mozilla better. I like the green
sans-serif of mozilla better than the grey monospace of ie. They are also
collapesable in mozilla. :-)

Although overall the fonts used in mozilla are a bit larger in size than that
used in IE. I probably would go for the bit smaller font size.

    
    

    
  
People often describe tabular data, diagrams, etc, using comments. It seems to
me that retaining comments as-is is a safe bet.

    
    

    
  
on comments i agree, i'll make those sustain whitespace in the next checkin

    
    

    
  
And before everybody goes wild about how the new colorscheme is ugly. It is now
using the same colors as viewsource, for the sake of consitency. Bug 173648 is
filed for making viewsource (and thus xml-prettyprint) use nicer colors

    
    

    
  
> CDATA has no different meaning from textnodes

In the DOM, CDATA is not the same as a text node. Therefore, unless XSLT sucks
mightily, it should be trivial to do this just like IE.

    
    

    
  
Standard XSLT doesn't distinguish between CDATA and regular text nodes. It
treats them all as "text".

    
    

    
  
OK, but script in XBL documents looks silly :-) Sorry for the misquote.

    
    

    
  
Ian: XSLT transforms XML documents which does not distinguish between text 
nodes and CDATA, it would be illegal to the standard to do so. That the 
current XSLT transformation engine uses DOM to do its work probably does not 
mean that you can go around breaking that rule.

Which takes me to the remark I wanted to make (and the implementers of this 
patch will probably hate me for this): I have the feeling Microsoft doesn't 
use XSLT (anymore?) to do the transformation. Why? Two reasons:

a) Output seems to be streamed. I can open a really large XML document 
(100+MB) and I'll get instant output, growing by the second.

b) When the XML document is invalid the output will be generated up to the 
position of the error and the error message will appear below that.

Point b) I can live without although it's cool to have but point a) is a bit 
more problematic.

I guess Microsoft implements this using SAX and custom visualisation code? Or 
is the current version of their transformer capable of streaming its output 
while still busy transforming?

Anyway, what do you all think about this?

    
    

    
  
> on comments i agree, i'll make those sustain whitespace in the next checkin

Would also be nice to have a color on class="markup" so that "<", "</", etc, are
colored just as you had before (doesn't have to be blue -- it might be refined
in bug 173648 as well).

    
    

    
  
Looks very neat so far. But here's some fun probably unreproducable bugs for ya:

1) I clicked the w3c URL. Worked fine.
   Then viewed the first attachment. Saw a tree view for it, but no colors
   Load the w3c URL again. Also no colors.

So I restart mozilla.

2) Load w3c URL. fine, with colors.
   View first attachment. Now it's not getting tree view! Just shows: 
     raboof hiihaa, and the raboof is not pastable
   When I reload, it randomly gives me eaither tree view or "styled" (but
      without any styles) view

Linux 2002101108.

    
  
Summary: [RFE] Better Default layout for "vanilla" XML documents → Better Default layout for "vanilla" XML documents

    
    

    
  


  
since the syncloader was the only thing in transformiix.xpt there is no longer
a transformiix.xpt. This patch removes it from xpinstall, embedding apparently
never shipped with this.

    
  

        Attachment #103122 -
        Flags: review+

    
    

    
  
Comment on attachment 103122 [details] [diff] [review]
remove transformiix.xpt from packager

r/sr=darin

    
    

    
  
Comment on attachment 103122 [details] [diff] [review]
remove transformiix.xpt from packager

sr=bzbarsky

        Attachment #103122 -
        Flags: superreview+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        stage three! (obsolete)
        — 
          — Splinter Review
      

    


  
Yes folks, this is the final, last and ultimate stage of prettyprinting in
mozilla.

This adds code to observe the document and then drops the binding if any
(non-anonymous) content is added. The reason that it doesn't trigger on
anonymous content is so that collapsing/expanding the treeview won't drop the
binding.

Much of this patch is refactoring the prettyprint code out to it's own class.
The entire nsXMLPrettyPrinter::PrettyPrint function is just moving code from
nsXMLContentSink::MaybePrettyPrint. Only exception is the last few lines below
the comment

// Observe the document so we know when to switch to "normal" view


There is one uglyness with this patch. In order to keep the observer alive it
manually addrefs itself. This since the document doesn't keep strong references
to it's observers. Suggestions wellcome on a nicer way to do this.

The only thing that this patch doesn't do is to fix the fact that the urls to
the images are hardcoded. I'm looking in to how to fix this, but that shouldn't
affect any of the coding so feel free to start reviewing.

    
    

    
  
I can't try it myself yet, as my build is still spinning, but last time I tried
it formatting was lost when changed character coding through View menu. Is still
addressed already?

    
    

    
  
Comment on attachment 103122 [details] [diff] [review]
remove transformiix.xpt from packager

a=rjesup@wgate.com

        Attachment #103122 -
        Flags: approval+

    
    

    
  
r=hyatt on the XBL changes.


    
    

    
  
Comment on attachment 103122 [details] [diff] [review]
remove transformiix.xpt from packager

checked in

    
    

    
  

      
      
      
      

        Attached patch
          
          
        stage three! v1.1 (obsolete)
        — 
          — Splinter Review
      

    


  
fixes review comments from hyatt and fixes a crasher

        Attachment #103150 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 103250 [details] [diff] [review]
stage three! v1.1

In MaybePrettyPrint (not shown here), comment "// Check for correct
load-command or if we're in a display:none iframe" is no longer accurate--no
check for display:none iframe yet.

In ~nsXMLPrettyPrinter, you shouldn't have to do the document remove at all,
but if you do RemoveObserver(), you should RemoveBinding to be consistent.

r=jkeiser

        Attachment #103250 -
        Flags: review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        stage three! v1.2 (obsolete)
        — 
          — Splinter Review
      

    


  
fixes comments from jkeiser and Hixie

        Attachment #103250 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 103264 [details] [diff] [review]
stage three! v1.2

r=jkeiser

        Attachment #103264 -
        Flags: review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        stage three! v2 (obsolete)
        — 
          — Splinter Review
      

    


  
eek, i forgot that i had changes in layout as well. This is the entire patch

        Attachment #103264 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        stage three! v2.1 (obsolete)
        — 
          — Splinter Review
      

    


  
* adds some comments requested by jkeiser
* adds an explicit call to binding->MarkForDeath()
* adds an extra check so that we don't prettyprint parseerror-pages
* renames RecreateFramesForNode to RecreateFramesFor
* switches to use good interfaces instead of nsIPref
* moves the check for display:none iframes to the nsXMLPrettyPrinter object

phew, that's all

        Attachment #103273 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 103404 [details] [diff] [review]
stage three! v2.1

r=jkeiser

        Attachment #103404 -
        Flags: review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        switch back to +/- (obsolete)
        — 
          — Splinter Review
      

    


  
I had a discussion with hewitt about how to do the twisties in a good way.
Currently there is no place where I can put the css-rules needed for this so we
decided to drop the twisities in favour of +/-.

Eventually we should have skinfiles for skinning things in the content-area and
when that happens it should be possible to get twisties again.

    
    

    
  
Comment on attachment 103430 [details] [diff] [review]
switch back to +/-

r/sr=bzbarsky

        Attachment #103430 -
        Flags: superreview+

    
    

    
  
Comment on attachment 103404 [details] [diff] [review]
stage three! v2.1

sr=rpotts@netscape.com

        Attachment #103404 -
        Flags: superreview+

    
    

    
  


  
fixes review comments by rpotts

        Attachment #103404 -
        Attachment is obsolete: true

        Attachment #103430 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 103495 [details] [diff] [review]
stage three! v2.2

moving forward reviews

        Attachment #103495 -
        Flags: superreview+

        Attachment #103495 -
        Flags: review+

    
    

    
  
Comment on attachment 103495 [details] [diff] [review]
stage three! v2.2

a=asa for checkin to 1.2 (on behalf of drivers).

        Attachment #103495 -
        Flags: approval+

    
    

    
  
this bug is FIXED!!

Thanks to everybody that reviewed, came with constructive ideas and made
testsuits (Ian, you rock!). Also want to thank netscape for paying me to
implement this :)

Bug 175946 has been filed for the missing parts of the prettyprint tree.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
This doesn't seem to be working for me in Mac OS X build 2002102208. I've
visited http://www.w3.org/Math/characters/entities.xsl and other urls in the bug
as well as other xml pages that I know that used to work in the last nightly
build I tried them with before. I have user_pref("layout.xml.prettyprint",
true); in my user.js file.

    
    

    
  
There is no platform specific code in there so i see no reason why Mac OS X
should be broken. Has anybody else tried this on OS X? Did it work?

    
    

    
  
I know it was working back on Oct 9th when I made comment #185, although I don't
remember what build I was using then. But it doesn't work now. The nightly
snapshots only go back to the 15th. I tried that build and I didn't seem to work
then either. :-(

    
    

    
  

      
      
      
      

        Attached file
          
        RTL XML testcase
        — 
      

    


  
I tested with this XML document containing right-to-left text, in both content
and markup.

In some elements the < and > participate in reordering, e.g. <<EMAN
Also, </NAME> is displayed as <EMAN/> which is confusing.

    
    

    
  
Reloading http://www.hixie.ch/tests/evil/xml/001b.xml over and over again causes
it to sometimes be pretty printed and sometimes not.

Also, there appears to be a race condition in this test: 
   http://www.hixie.ch/tests/evil/xml/001.xml
Sometimes, the page shows up blank, sometimes it shows up with the pretty
printer, and sometimes it shows up with the green background and text "Hello
World!". It should always do the latter. Note: enable popups before visiting
this test.



    
    

    
  
>Reloading http://www.hixie.ch/tests/evil/xml/001b.xml over and over again causes
>it to sometimes be pretty printed and sometimes not.

I'm seeing exactly the same as this with a local XML file (although it seems to 
heppen with any XML doc). There seems to be no pattern in whether it is pretty 
printed or not. From my non-exhaustive tests, it takes between 1 and 8 reloads to 
change mode if in non-pretty mode and between 1 and 4 if in pretty mode (dunno if 
that helps at all).

Gecko/20021125

    
    

    
  
-> bug 182031
Status: RESOLVED → VERIFIED

    
    

    
  
I can confirm that Prettyprinting does NOT work in Mac OS X with 1.2 Final.

    
    

    
  
The final 1.2 release doesn't work on my Mandrake 9.0 Linux either. I added the
following line in the prefs.js file:

     user_pref("layout.xml.prettyprint", true); 

but it still didn't show any content of the xml files on the local disk or from
the internet. 

Moreover, as soon as the browser is closed, the line mentioned above gets
deleted automatically from prefs.js

    
    

    
  
Re: Comment #225:
  Edit user.js, not prefs.js. Then, after editing user.js, restart Mozilla.

    
    

    
  
Does not work on 1.2 Final on Mac OS X.
( user_pref("layout.xml.prettyprint", true); in user.js)

    
    

    
  
Maybe all the breakage is related to 182031?

    
    

    
  
Does not work under 1.2.1 on Windows 2000 either.  Had worked reliably in 1.2a
and 1.2b.  Did the final release break something?

    
    

    
  
Where is user.js located? I don't see it anywhere under my .mozilla directory.
Do I need to create it manually and just include only the following line in it:

    user_pref("layout.xml.prettyprint", true); 

?

Thanks.

    
    

    
  
chunnuan, that is not necessary. it should work by default.

    
    

    
  
anyone having problems getting this to work, please head over to bug 182031.
Please ready _all_ of that bug since it contains important updates.



    
    

    
  
Thanks, Chris. It does work by default. However it doesn't seem to work
consistently. Sometimes I have to reload the file more than once to see the
prettyprinting, which may be related to the bug pointed out by Jonas in the
previous note.


One more thing I noticed is that the print preview  shows only one page for the
whole xml file, no matter how large it is, and the printer also prints only one
page. Is this a known bug?

    
    

    
  
bug 185873 filed on the printing issue.

chunnuan: PLEASE head over to bug 182031. And read ALL of that bug before posting.

    
  
Blocks: 188130

    
  
No longer blocks: majorbugs

    
    

    
  
Could anyone take a look at bug #263049, is a big prettyprint issue with 10 years ...

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: