Closed Bug 182031 Opened 22 years ago Closed 19 years ago

Pretty-printer not always used

Categories

(Core :: XML, defect)

Product:
Core
Component:
XML
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ian, Assigned: sicking)

References

(
URL
)

Details

Attachments

(1 obsolete file)

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.
After 31 shift-reloads, I saw this on linux 2002112108.
OS: Windows 2000 → All
Hardware: PC → All
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
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.
Flags: wanted1.3a?
*** Bug 182548 has been marked as a duplicate of this bug. ***
pretty print is never shown for this URL: http://phpsysinfo.sourceforge.net/phpsysinfo/?template=xml
>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.
Flags: blocking1.3a? → blocking1.3a-
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. ***
Attached patch this should hopefully fix it (obsolete) — — Splinter Review
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) → 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
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
This is fixed in the latest Phoenix nightly (20021216 Win2K). Many thanks Jonas!!!
Thanks! windows confirmed, linux and mac to go...
Working on Mac OS X Build 2002121608. Shweeeet!
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?
This still doesn't seem to work on Linux, Build 2002-12-17-08-trunk
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?
It doesn´t work on Linux consistently. I reloaded 20 times or so.
This is still happening on the trunk build 2002-12-20-08-trunk on win2K .
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.
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.
*** Bug 192339 has been marked as a duplicate of this bug. ***
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
QA Contact: rakeshmishra → ashishbhatt
marking new since i'm not working on these
Status: ASSIGNED → NEW
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.
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?
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 =)
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
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: