Pretty-printer not always used

RESOLVED WORKSFORME

Status

()

--
minor
RESOLVED WORKSFORME
16 years ago
13 years ago

People

(Reporter: ian, Assigned: sicking)

Tracking

Trunk
All
Linux
Points:
---
Bug Flags:
blocking1.3a -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

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

The problem also occurs with data:text/xml,<test/>

It is intermittent, and occurs about 5% of the time.

Comment 1

16 years ago
After 31 shift-reloads, I saw this on linux 2002112108.
OS: Windows 2000 → All
Hardware: PC → All

Comment 2

16 years ago
I get this far more than 5% of the time. When I reload, there is about a 70% 
chance that the doc will not be pretty-printed. Win2K 20021125

Comment 3

16 years ago
I have the same problem with local XSLT and XSD files using Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126
It seems to be completely random.
(Reporter)

Updated

16 years ago
Flags: wanted1.3a?
*** Bug 182548 has been marked as a duplicate of this bug. ***

Comment 5

16 years ago
pretty print is never shown for this URL:
  http://phpsysinfo.sourceforge.net/phpsysinfo/?template=xml

Comment 6

16 years ago
>pretty print is never shown for this URL:
>http://phpsysinfo.sourceforge.net/phpsysinfo/?template=xml

Does this have something to do with Mozilla thinking this is an HTML file? - if
you do "Save As" it trys to save with an HTML extension.
yes, the server is sending text/html as mimetype for that file. Prittyprinting
is only for xml.

Updated

16 years ago
Flags: blocking1.3a? → blocking1.3a-

Comment 8

16 years ago
The same problem here with 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
About 50% of the time, the XML is pretty-printed
*** Bug 183673 has been marked as a duplicate of this bug. ***
Created attachment 109320 [details] [diff] [review]
this should hopefully fix it

Since i can't reproduce on windows i havn't tested if this fixes the problem.
Bryner noticed that one codepath doesn't initialize mLoading which means that
nsSyncLoader::Load might never set mLoadSuccess to true. This will make
nsSyncLoader::LoadDocument think that the load fail.

End result is that the XSLT stylesheet isn't loaded and the prittyprinting
aborts.
Attachment #109320 - Flags: review+
Attachment #109320 - Flags: superreview?(peterv)
Attachment #109320 - Flags: superreview?(peterv) → superreview+
Comment on attachment 109320 [details] [diff] [review]
this should hopefully fix it

checked in.
Attachment #109320 - Attachment is obsolete: true
Since i was never able to reproduce this i'm not fully sure this is fixed. It
would be great if people that were able to reproduce this could try with a build
from 12/16 or newer once available.
Status: NEW → ASSIGNED

Comment 13

16 years ago
This is still happening on the trunk build 2002-12-16-04-trunk on win2K .
hmm.. that's a few hours early. Please try with something from 2002-12-16-09 or
later. Thanks

Comment 15

16 years ago
This is fixed in the latest Phoenix nightly (20021216 Win2K). Many thanks Jonas!!!
Thanks!
windows confirmed, linux and mac to go...

Comment 17

16 years ago
Working on Mac OS X Build 2002121608. Shweeeet!

Comment 18

16 years ago
This still doesn't seem to work on Linux. The URL of this bug gives me an empty
page. The URL from the dupe still displays the content of the document ("Returns
current temperature in a given U.S. zipcode  ").

Tested with a fresh CVS build updated an hour ago.
(user_pref("layout.xml.prettyprint", true); is set in my prefs.js)
Stefan: could you check that your build contains the patch in attachment 109320 [details] [diff] [review]?
There were some hickups with the servers right after i checked in.

Anybody else can confirm wether this works or doesn't work on linux?

Comment 20

16 years ago
This still doesn't seem to work on Linux, Build 2002-12-17-08-trunk

Comment 21

16 years ago
Jonas: I checked if the patch is in my tree and it is indeed.
Ok, this seems to be limited to linux now. Which unfotunatly doesn't help much :(

Does it never work, or does it work on and off?
OS: All → Linux
when reloading the bug url multiple times, does it work on and off? Or does it
fail a first few times and after that work consistently?

Comment 24

16 years ago
It doesn´t work on Linux consistently. I reloaded 20 times or so.

Comment 25

16 years ago
This is still happening on the trunk build 2002-12-20-08-trunk on win2K .

(Reporter)

Comment 26

16 years ago
I can no longer reproduce this bug with a recent trunk build.
can anybody still reproduce this?

Even better would be if someone that has a buildenvironment and that can
reproduce this would let me know and i'll write up a patch to aid in the debugging. 

Comment 28

16 years ago
I can still reproduce this bug. The situation hasn't changed since my comment #18.
I just updated my build from CVS and can try patches to track down the problem.

Comment 29

16 years ago
*** Bug 192339 has been marked as a duplicate of this bug. ***

Comment 30

16 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

This is constantly reproducible. If I load any XML file, e.g. \Program
Files\mozilla.org\Mozilla\res\builtin\htmlBindings.xml I just get a blank window
no matter how many times I reload it. However, View->Page Source shows the file
contents.

A dubug build yields this:

WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(result)) failed, file e:/mozilla_src/mozill
a/content/xml/document/src/nsXMLContentSink.cpp, line 1826
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file e:/mozilla_src/mozilla/co
ntent/xml/document/src/nsXMLPrettyPrinter.cpp, line 152
Document file:///E:/Program%20Files/mozilla.org/Mozilla/res/builtin/htmlBindings
.xml loaded successfully

The call to do_CreateInstance() appears to be failing:

    // Transform the document
    nsCOMPtr<nsIXSLTProcessor> transformer =
        do_CreateInstance("@mozilla.org/document-transformer;1?type=text/xsl", &rv);
    NS_ENSURE_SUCCESS(rv, rv);



that's bug 199484, a recent regression

Updated

16 years ago
QA Contact: rakeshmishra → ashishbhatt
marking new since i'm not working on these
Status: ASSIGNED → NEW

Comment 33

15 years ago
On Mozilla 1.7 under Linux, it seems that the XML prettyprinter is never used.
Same problem here. Neither firefox 0.9.1 nor mozilla 1.7 seems to be using the
pretty printer at all...
Ari & Mathieu, if you are on a Debian system it appears the Debian-modified
Mozilla versions have a bug where the pretty printer is never used. Another
thing to check is make sure that the file you are viewing has an XML mime type.

This bug is about the pretty printer occasionally failing.
I'm not using debian. I can reproduce this with a firefox 0.9.1 build that comes
from mozilla.org and a mozilla 1.7 build compiled from source.
I'll see if I can reproduce it on other boxes and I'll open a new bug.

Comment 37

13 years ago
Opening an XML document with File->Open... always shows the pretty printer.  Opening that same file through http://.... never shows it.

Response headers:
HTTP/1.x 200 OK
Date: Fri, 13 Jan 2006 21:03:59 GMT
Server: Apache/2.0.49 (Fedora)
Last-Modified: Fri, 13 Jan 2006 21:01:18 GMT
Etag: "26909c-31-40a43c4390380"
Accept-Ranges: bytes
Content-Length: 49
Connection: close
Content-Type: text/xml

Firefox: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Anthony: Could you attach a testcase?

Comment 39

13 years ago
To be honest, I was googling for a solution and ended up here.  After a little more thinking, I found out that the cause is actually in my profile.  

https://bugzilla.mozilla.org/attachment.cgi?id=31654

For example, shows an empty window, but when I create a new blank profile and go there, I see the pretty-printed XML file as expected.  I'll continue to dig for what the purpose is, but I probably should have never posted here =)

Comment 40

13 years ago
LiveHTTPHeaders.  Not surprised now that I found it.  Thanks for the fast response anyway =)
Closing this as WORKSFORME, if anyone can get it to fail please reopen
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.