Closed
Bug 647863
Opened 15 years ago
Closed 4 years ago
Page with <canvas> tag fails to render at all
Categories
(Core :: XSLT, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: Rob.Simpson, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Page with <canvas> tag at http://www.HTML-5.com/tags/canvas-tag/index.html does not render at all in Firefox 4.0 for Windows. The page renders fine in Firefox 4.0 for Mac "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0" and other browsers on both platforms.
Reproducible: Always
Steps to Reproduce:
1. Go to http://www.HTML-5.com/tags/index.html#embedded-content-tags
2. The page should automatically scroll to the section with the <canvas> tag in it, but if it doesn't, put the cursor in the address bar and hit Return. (Not honoring the fragment identifier in the URL is a regression from May 2010, Firefox Bug #645075.)
3. Click on the second link: "<canvas tag>". Should display that page like other browsers do, but Firefox just stays on the index page.
4. Right click on that link and "Open Link in New Tab". No joy there either.
5. Try some of the other links, and they pretty much all work OK.
6. Try the steps 1-4 above in other browsers and it works.
6. In a browser where the page gets displayed, scroll to the bottom of the page and click "Valid HTML 5". The W3C Markup Validation Service shows it's valid HTML.
Actual Results:
Page does not render at all in Firefox 4.0 for Windows
Expected Results:
Should render the page like in other browsers.
The only thing the error console shows is:
Warning: Unknown property '-moz-outline'. Declaration dropped.
Even though the "software hangs", I'm not sure if this deserves "Cricical" severity.
Updated•15 years ago
|
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Comment 1•15 years ago
|
||
I see this in Firefox 3.6 as well. And I'm on Mac.
Jonas, what happens here is that nsXMLContentSink::DidBuildModel is called and nulls out mXSLTProcessor after starting the transform. Then before the transform is done, onload fires for a child document (URI is about:blank; frame element is null) which flushes _layout_ on the parent document, which is the XML document we're parsing. And since mXSLTProcessor is null, we start layout. Then in OnTransformDone we blow away the old document + presshell, try to start layout on the new one, but bail out because we think we started layout already. We should consider resetting that mLayoutStarted boolean to false when we blow away the old document+shell, but the fact that we start layout on the pre-transform document to start with seems broken....
Status: UNCONFIRMED → NEW
Component: General → XSLT
Ever confirmed: true
QA Contact: general → xslt
Punting this one to Peter
Comment 3•4 years ago
|
||
Marking this as Resolved > Worksforme since the issue is no longer reproducible on the latest versions of Firefox Nightly 96.0a1 (2021-11-23), beta 95.0b10 or release 94.0.2 on Windows 10, Ubuntu 20.04 and Macos 11.6.
If anyone is still able to reproduce this issue either re-open this ticket or file a new one.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•