The default bug view has changed. See this FAQ.

Transformation of Universal MathML Stylesheet doesn't complete

VERIFIED FIXED

Status

()

Core
XSLT
VERIFIED FIXED
15 years ago
14 years ago

People

(Reporter: rbs, Assigned: sicking)

Tracking

Trunk
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments, 4 obsolete attachments)

(Reporter)

Description

15 years ago
With the first testcase which invokes "pmathml.xsl", the transfromation never
completes, and so "Hello to pmathml.xsl" is never displayed on the page.
I used a printf() in nsXSLContentSink::DidBuildModel() and it didn't show up.
This means onTransformDone() is never called.

With the second testcase which invokes "mathml.xsl", the transformation completes
successfully. The paradox to note is that "mathml.xsl" is including "pmathml.xsl"
as can seen with the view-source protocol here (copy the full "v-s:URL" into the
URL bar to see the syntax-higlighted source of the XSLT stylesheet):
view-source:http://www.w3.org/Math/XSL/mathml.xsl
view-source:http://www.w3.org/Math/XSL/pmathml.xsl

First testcase with pmathml.xsl (bug here)
==========================================
<?xml-stylesheet type="text/xsl"
                 href="http://www.w3.org/Math/XSL/pmathml.xsl"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>pmathml.xsl</title></head>
<body>
Hello to pmathml.xsl
</body>
</html>

Second testcase with mathml.xsl (no bug here)
=============================================
<?xml-stylesheet type="text/xsl"
                 href="http://www.w3.org/Math/XSL/mathml.xsl"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>mathml.xsl</title></head>
<body>
Hello to mathml.xsl
</body>
</html>

I will attach these testcases. 

During testing, note that the title of the window is set properly in either
case, but the content area isn't updated in the the first testcase due to the
fact that the transformation is not completing as I mentioned above.
(Reporter)

Comment 1

15 years ago
Created attachment 92086 [details]
testcase with pmathml.xsl (bug here)
(Reporter)

Comment 2

15 years ago
Created attachment 92087 [details]
testcase with mathml.xsl (no bug here)
This seems to have something to do with scriptloading. It looks like we're
blocking the parser for a script load in the stylesheet but never unblock it.
Reassigning to sicking for now.
Assignee: peterv → sicking
(Reporter)

Comment 4

15 years ago
Nominating for 1.0.1 and 1.1 since this bug is an impediment to using all
flavors of the Universal MathML stylesheet.
Keywords: mozilla1.0.1, mozilla1.1
(Reporter)

Comment 5

15 years ago
sicking, perhaps this bug might be fixed by what you said in bug 132844 comment 22?
no, that shouldn't affect this. I think it whould be fixed if we didn't create
nsHTMLScriptElements for <script>s in the stylesheet document (which we
shouldn't do anyway). However I need to do some reshuffeling in the contentsink
to be able to do that. I will hopefully get time to look at this really soon

Comment 7

15 years ago
note that a 
<meta content="0;URL=../{/redirect/url}.{$ext}" http-equiv="Refresh"/>
with a xhtml namespace triggers a redirect from the stylesheet, so it doesn't
matter if the meta actually makes it into the content, or if there are AVTs to
be applied.

Comment 8

15 years ago
The test cases that have been attatched refer to the public copy of
pmathml.xsl at w3c.org
Note I am about to update that copy to use <SCRIPT rather than <script
so that enables the stylesheet to work again in mozilla1.1 and NS 1.0
(note the old code worked in mozilla 1.0 and NS 7 pre-release)

so this is to note that the test cases should refer to local copies of the 
stylesheet that use <script otherwise they will no longer demonstrate the 
problem.

The <script in question is not activated at all in mozilla it is in conditional 
code only used in IE (the page still does not display if you surround the 
<script> element with <xsl:if test="false()">...
(Reporter)

Comment 9

15 years ago
*** Bug 161087 has been marked as a duplicate of this bug. ***

Comment 10

15 years ago
*** Bug 174353 has been marked as a duplicate of this bug. ***
Created attachment 103446 [details] [diff] [review]
patch to fix

The problem was that the XSL sink unregistered itself as nsIScriptLoadObserver,
this caused us to not get the neccesary notification leaving the parser
blocked. Note that we need to get (and do get if we are an observer) this
notification even if the scriptloader is disabled.

So the fix is to simply remove the line that unregisters ourself and it should
work. However that was way too easy :), so the patch does the following:

* Cleaning up the initialization of stylesheet loading in the xml-contentsink
by
  making it properly call nsIDocument::StartDocumentLoad.
* Rely on the fix from bug 172372 to stop stylesheet and script loads.
* Remove the manual disabling of stylesheet and script loads in the
  xsl-contentsink.

(obsoleting the testcases since they no longer work)
Attachment #92086 - Attachment is obsolete: true
Attachment #92087 - Attachment is obsolete: true
as always when i'm attaching patches at this hour there are some quirks in them.
Ignore the empty files please, they are part of other fixes
*** Bug 173034 has been marked as a duplicate of this bug. ***
Comment on attachment 103446 [details] [diff] [review]
patch to fix

sr=peterv. While you're tweaking things in there you might want to set the
referrer on the channel for the stylesheet (see the comment just below your
change in nsXMLContentSink.cpp).
Attachment #103446 - Flags: superreview+
Created attachment 103632 [details] [diff] [review]
sync to tip and set the refferer

fixes petervs comment and sync the patch to the tip
Attachment #103446 - Attachment is obsolete: true

Comment 16

15 years ago
Comment on attachment 103632 [details] [diff] [review]
sync to tip and set the refferer

> 
>   nsCOMPtr<nsIChannel> channel;
>   rv = NS_NewChannel(getter_AddRefs(channel), aUrl);
>   if (NS_FAILED(rv)) return rv;
> 
>+  nsCOMPtr<nsILoadGroup> loadGroup;
>+  rv = mDocument->GetDocumentLoadGroup(getter_AddRefs(loadGroup));
>+  NS_ENSURE_SUCCESS(rv, rv);
>+
>+  channel->SetLoadGroup(loadGroup);
>+

Nit: Can't you delay the channel creation until a load group is available?
Attachment #103632 - Flags: review+
Created attachment 103646 [details] [diff] [review]
fix harishs comment
Attachment #103632 - Attachment is obsolete: true
Comment on attachment 103646 [details] [diff] [review]
fix harishs comment

moving forward reviews
Attachment #103646 - Flags: superreview+
Attachment #103646 - Flags: review+

Comment 19

15 years ago
Comment on attachment 103646 [details] [diff] [review]
fix harishs comment

a=asa for checkin to 1.2 (on behalf of drivers)
Attachment #103646 - Flags: approval+
fix checked in
Status: NEW → ASSIGNED
wrong button :)
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 22

15 years ago
Re-opening, I am still experiencing the bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 23

15 years ago
Created attachment 107189 [details]
pmathml.xsl with <script>
(Reporter)

Comment 24

15 years ago
Created attachment 107190 [details]
pmathml.xsl with <SCRIPT>
(Reporter)

Comment 25

15 years ago
Created attachment 107191 [details]
testcase that uses pmathml.xsl with <script> (bug here)
(Reporter)

Comment 26

15 years ago
Created attachment 107194 [details]
testcase that uses pmathml.xsl with <SCRIPT> (no bug here)

I have set the background color of the working testcase to green. To clearly
see the bug, click on either of the testcases, and then go and then go forward.

The working testcase (with its green background color) will appear properly,
whereas the other one (with its white background color) is still not rendered.
*** Bug 184159 has been marked as a duplicate of this bug. ***

Comment 28

15 years ago
Adding URL from bug 184159
OS: Windows -> All
Shouldn't severity be increased due to browser hang?
OS: Windows 2000 → All
Still don't fully understand why this wasn't fixed by my last checkin (i do
think it fixed my local testcase i had). However this should be fixed now along
with bug 169124
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
The url in the URL field hangs build 2002-11-07-21, but not 2002-11-06-22 on
Linux.. anything in that range look suspicious?
Sorry, man.  Look at the build date in bug 184159.  And I'm using 2002-12-04-22
on Linux and hanging... (169124 was checked in on the second).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
looks like bug 184159 is something different, this one is fixed.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
regarding my comment 29. The reason why this wasn't fixed by my first patch
didn't fix attachment 107191 [details] is that that stylesheet contains <script
for="...">. Normal scripts got fixed, but the for-attribute still messed up
things. They still do when they are in an included stylesheet, which is what bug
184159 is about.

Comment 34

14 years ago
*** Bug 187502 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

14 years ago
Blocks: 184159
(Reporter)

Updated

14 years ago
Blocks: 205778

Comment 35

14 years ago
mass verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.