Bug 37445 – [Qt] Regression: Google calendar edit event details gets stuck on loading

• Status: RESOLVED
• Resolution: INVALID
• Component: Layout and Rendering

[Jocelyn Turcotte]

- Go to Google calendar, log in
- Click on "Create Event" on the left menu (or click in the calendar to create an event and click "edit event details")

Expecting to see the edit event panel

Got instead a big white panel and sometimes the "Loading..." notice in the top right corner stays on.
The website cannot be used.

Reproduced in QtLauncher on Windows 7 with Qt 4.7 trunk and WebKit trunk
Could not reproduce the problem in the demo browser of Qt 4.5.3

[Jocelyn Turcotte]

Created attachment 54718 [details]
Patch: Disable XSLT

The problem turns out to be a bug in Qt's xmlpattern.
See: http://bugreports.nokia.troll.no/browse/QTBUG-10309

Mozilla's xslt test page is broken as well since Qt's xslt implementation doesn't support xsl:attribute-set yet.
http://www.mozilla.org/projects/xslt/test.xml

This patch sets xslt in QtWebKit as disabled by default

[Jakub Wieczorek]

Created attachment 54748 [details]
A patch for Qt

Thanks for CCing me.

(In reply to comment #1)
> Created an attachment (id=54718) [details]
> Patch: Disable XSLT
> 
> The problem turns out to be a bug in Qt's xmlpattern.
> See: http://bugreports.nokia.troll.no/browse/QTBUG-10309

I posted a comment on that bug about why I think this doesn't work:

"I don't think http://www.w3.org/TR/xslt#dt-shadows is what matters here. The specified parameters for a template should not be inherited by a nested call of another template in the first place, so shadowing does not seem to apply here. I'm pretty sure that the actual problem here is that the processor maintains one list of the parameter values that it should supply to the template being called. In this case it reuses the same list for a nested call when computing the subtree of the param2 parameter, which is when it hits the duplicate."

I think it would be better if this particular bug was simply fixed instead of the whole thing disabled. I'm attaching a patch for QtXmlPatterns that could be a possible solution. I haven't tested it properly yet, I only checked your test case as well as the other one posted on that bug, they both work fine with the patch.

Provided that isn't too late to get this into Qt so that XSLT does not have to be disabled in QtWebKit, I'm going to prepare an official merge request with the patch tomorrow after I make sure it's correct.

[Jakub Wieczorek]

(In reply to comment #2)
> Provided that isn't too late to get this into Qt so that XSLT does not have to
> be disabled in QtWebKit, I'm going to prepare an official merge request with
> the patch tomorrow after I make sure it's correct.

http://qt.gitorious.org/qt/qt/merge_requests/2376

[Jocelyn Turcotte]

Comment on attachment 54718 [details]
Patch: Disable XSLT

Removing flags on the patch until we see how it goes by fixing Qt's xslt

We should also see if we disable is for Qt 4.6 or get the xslt fix in Qt 4.6.3 as well

[Kenneth Rohde Christiansen]

Are you following up on getting this fix into Qt, Jocelyn?

[Jesus Sanchez-Palencia]

Reproduced on Snow Leopard with Qt 4.7 trunk (HEAD 03f8f1df0d88f5ffe0b3120cffce614cbeefdb70) and WebKit trunk (r59155), using QtLauncher.

[Jocelyn Turcotte]

(In reply to comment #5)
> Are you following up on getting this fix into Qt, Jocelyn?

XSLT has been disabled in the qtwebkit-2.0 branch at the commit 25c6b4daf01b70fe8cd368f78bb7e8257085c0b1.

Fixing only this bug in Qt might not be enough. The documentation states that the XSLT support in Qt is still experimental and passes 42% of the XSLT test suite.
http://doc.trolltech.com/4.7/xmlprocessing.html#xslt-2-0

IMHO I think that we should try to support a good part of XSLT 1.0 use cases before enabling it in a QtWebKit release since web sites might rely on the XSLTProcessor being supported totally or not at all.

[Simon Hausmann]

Removing this issue from the 2.0 release blockers, as we've applied the workaround there to disable XSLT.

[Laszlo Gombos]

Would XSLT support significantly improve in Qt 4.8 ? I do not see progress on the original bug - http://bugreports.qt.nokia.com/browse/QTBUG-10309.

[Jocelyn Turcotte]

(In reply to comment #9)
> Would XSLT support significantly improve in Qt 4.8 ? I do not see progress on the original bug - http://bugreports.qt.nokia.com/browse/QTBUG-10309.

I don't think anybody of Qt is working on this, especially since Frans left the company.

[Laszlo Gombos]

(In reply to comment #10)
> (In reply to comment #9)
> > Would XSLT support significantly improve in Qt 4.8 ? I do not see progress on the original bug - http://bugreports.qt.nokia.com/browse/QTBUG-10309.
> 
> I don't think anybody of Qt is working on this, especially since Frans left the company.

I see 2 options here - plan on turning off XSLT longer term (perhaps turn it off even on trunk)  or switch to libxslt.

[Laszlo Gombos]

Related e-mail thread about turning on XSLT and using libxslt as a back-end if available - https://lists.webkit.org/pipermail/webkit-qt/2011-November/002166.html

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.