User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20060606 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20060606 Firefox/184.108.40.206 When loading a prepared UTF-8 encoded xhtml file the text between a null byte and the next html tag is hidden. When loading that file from disk or loading that file from a webserver with content type text/html, the browser hangs or crashes. When loading it with xml content type, the first '<' of the next tag disappears and the xml file gets corrupted, but the browser does not crash. Reproducible: Always Steps to Reproduce: 1. load the file 2. see what happens Actual Results: hidden text, browser hangs or crashes Expected Results: visible text, no crash system default encoding is UTF-8
Created attachment 230868 [details] file that causes the crash Warning! Save your data before opening that file in your browser!
Created attachment 230869 [details] second example Warning! Save your data before opening that file in your browser!
Component: General → HTML: Parser
Product: Firefox → Core
Version: unspecified → 1.8 Branch
Assignee: nobody → mrbkap
QA Contact: general → parser
Do you crash on these testcases (loaded from the bug)? I don't using a ff2 debug build. Is my build fixed, or did the problem get stripped on upload?
Attachment #230868 - Attachment mime type: text/html → text/xml
Attachment #230868 - Attachment mime type: text/xml → text/html
I don't crash using a release 220.127.116.11 either
I don't crash using the first testcase with Linux Firefox 18.104.22.168 after saving to disk, on a system where the system encoding is UTF-8.
Yes, my browser crashes when loading the attached testcases. It's reproducable on two different systems, both are gentoo systems with firefox 22.214.171.124. Mozilla 1.7.13 on one of the systems does NOT reproduce the bug.
With the Firefox 126.96.36.199 latest debug build here on Solaris(I made it myself), the two testcases don't crash.
Additional info: I get the following notice on the console, when firefox hangs: (Gecko:19305): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()
Ok, it's not a gentoo thing. Report from a debian system: Firefox crashes (freeze): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20060406 Firefox/184.108.40.206 (Debian-1.5.dfsg+220.127.116.11-1) Epiphany does not crash, but refuses to show or save the html source: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20060608 (Debian-22.214.171.124-1) Epiphany/2.14
All those are pango-enabled releases and you got a pango warning -- a clue?. The official Mozilla Firefox binaries do not use pango, could you download and test a release from http://releases.mozilla.org/pub/mozilla.org/firefox and see if the problem goes away? If you still see the bug then we need to keep looking at what other differences might cause you to see this problem when we don't. If the bug goes away with official releases it's almost certainly related to pango. Might be in our use of pango, or in pango itself.
Assignee: mrbkap → nobody
Component: HTML: Parser → Layout
QA Contact: parser → layout
Summary: hidden text and browser crash when loading page with 0 byte and justified paragraph → [pango?] hidden text and browser crash when loading page with 0 byte and justified paragraph
We also have to determine if this is an unexploitable crash so we can open up the bug (and thus get more folks looking at it) or if it needs to remain security-sensitive.
I've got to look into it. Pango historically didn't allow embedded NUL. It will treat it as a premature end of string even if a length parameter is passed on. I'm going to fix that properly. Next is the fact that gfx/src/gtk/nsFontMetricsPango converts from UTF-16 to UTF-8 and calls strlen on the restult, assuming no embedded NUL. To fix it properly, Pango should be fixed to allow embedded NUL. That's not really too far. And nsFontMetricsPango should not make any such assumptions either. In the mean time, we can fix it in nsFontMetricsPango by replacing NUL bytes with a 0xff byte. You'll get the Pango warning, but it will work otherwise. I can cook a patch if this looks good.
Ok, trying to fix this led to an almost rewrite of the nsFontMetricsPango code. I wanted to clean it up for so long. Finally did. The final patch is attached to bug 357733. That one includes Pango printing bits too. For this bug, just picking the gfx/src/gtk changes is enough.
I'll take comment 12 and 13 as confirmation. Marking dependent on bug 357733 and removing security flag because the crash is not in Firefox.
Assignee: nobody → mozilla
Status: UNCONFIRMED → NEW
Depends on: 357733
Ever confirmed: true
Created attachment 412448 [details] first testcase, with � instead of null byte that gets turned into U+FFFD
None of these testcases crashes my Firefox trunk debug build on Ubuntu 9.10. I think mozilla.com builds use Pango, so I'm not sure what comment 14 was about.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 366902
You need to log in before you can comment on or make changes to this bug.