Issue with Kupu 1.4 and Firefox 3.6 - cannot save documents

Bug #512236 reported by Jon Bowlas
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Silva
Fix Released
Undecided
Unassigned

Bug Description

We think we've discovered an issue between Kupu and the latest version of Firefox (3.6,
released 21/01/10). As the page loads, a JavaScript error occurs, and it's
impossible to then save anything in Kupu.

We've fixed this by simply commenting out line 237 of 'sarissa.js', ie:

XMLDocument.prototype.readyState = 0;

This is giving JS errors, but it also seems like a bit of redundant code
that, as far as I understand, should never have worked in the first place:
XMLDocument's 'readyState' method should be used, I think, to get the value
of the HTTP state - it can't set it (as in the above code).

We've tested this, and are fairly sure that there are no hidden consequences
anywhere, although we'd be interested if anyone knows what the point of this
code was originally.

Changed in silva:
status: New → Confirmed
Revision history for this message
Andres Ederra (andres-ederra) wrote :

Hi,

In case it helps, the same error is ocurring when firefox was updated to 3.6 on ajaxterm project...

It seems the problem resides in the sarissa js library(http://dev.abiss.gr/sarissa/) both projects are using...

I'm registering a bug with ajaxterm too (https://bugs.launchpad.net/ubuntu/+source/ajaxterm), and i'm trying to update/hack sarissa and see what happens... lets join effors as it seems it is the same problem

Revision history for this message
Wim Boucquaert (wim-boucquaert) wrote : Re: [silva-new-issues] [Bug 512236] Re: Issue with Kupu 1.4 and Firefox 3.6 - cannot save documents

Hi Andres,

Included is a patch of the code we changed in sarissa.js to prevent the
problems in Firefox 3.6. Maybe you can use the same fix for ajaxterm?

Hope it helps.

Regards

Wim

Andres Ederra wrote:
> Hi,
>
> In case it helps, the same error is ocurring when firefox was updated to
> 3.6 on ajaxterm project...
>
> It seems the problem resides in the sarissa js
> library(http://dev.abiss.gr/sarissa/) both projects are using...
>
> I'm registering a bug with ajaxterm too
> (https://bugs.launchpad.net/ubuntu/+source/ajaxterm), and i'm trying to
> update/hack sarissa and see what happens... lets join effors as it seems
> it is the same problem
>

Kit Blake (kitblake)
Changed in silva:
status: Confirmed → Fix Committed
status: Fix Committed → Fix Released
Revision history for this message
Andres Ederra (andres-ederra) wrote :

Thanxs Wim,

I agree its a good low impact solution to patch sarissa 0.9.6.1, and yea, that also fixs ajaxterm problem. AFAIK that change doesn't have sideeffects...

But as a more permanent solution i was thinking about upgrading sarissa version to the lastest available, that newer version doesn't contain the offending code and there is no need to branch of patch the sarissa files so that the project can maintain itself in the same line as sarissa...

But that latest sarissa vesion has another issues we are trying to resolve with the sarissa team.

Next week, no later, I will issue a patch for ajaxterm, one way or another. Check it out in case you find it usefull.

Regards,

Andrés

Revision history for this message
Jean Jordaan (jean-jordaan) wrote :

The bug exists with kupu 1.3.9 as well.

Revision history for this message
Kit Blake (kitblake) wrote :

If you don't want to upgrade you could probably comment out the same sarissa code in 1.3.9.

Revision history for this message
Flemming Bjerke (flem) wrote :

I have done as described above, see below. But, it does not fix the bug. We don't use Silva, but plone on zope297 with Kupu 1.3.9, zope297. But, yes, there is no bug when I use seamonkey, but firefox.

I would be happy if any of you had suggestions to how I should fix the bug.

Flemming

.../Products/kupu/common/sarissa.js

else{ /* end IE initialization, try to deal with real browsers now ;-) */
   if(_SARISSA_HAS_DOM_CREATE_DOCUMENT){
        if(window.XMLDocument){
            /**
            * <p>Emulate IE's onreadystatechange attribute</p>
            */
            XMLDocument.prototype.onreadystatechange = null;
            /**
            * <p>Emulates IE's readyState property, which always gives an integer from 0 to 4:</p>
            * <ul><li>1 == LOADING,</li>
            * <li>2 == LOADED,</li>
            * <li>3 == INTERACTIVE,</li>
            * <li>4 == COMPLETED</li></ul>
            * FB has outcommented the following line:
            * XMLDocument.prototype.readyState = 0;
            */
            /**
            * <p>Emulate IE's parseError attribute</p>
            */

Revision history for this message
Flemming Bjerke (flem) wrote :

Sorry, the patch above do fix the problem:

 if(_SARISSA_HAS_DOM_CREATE_DOCUMENT){
        if(window.XMLDocument){
            /**
            * <p>Emulate IE's onreadystatechange attribute</p>
            */
            XMLDocument.prototype.onreadystatechange = null;
            /**
            * <p>Emulates IE's readyState property, which always gives an integer from 0 to 4:</p>
            * <ul><li>1 == LOADING,</li>
            * <li>2 == LOADED,</li>
            * <li>3 == INTERACTIVE,</li>
            * <li>4 == COMPLETED</li></ul>
            * FB har ukommateret
            * XMLDocument.prototype.readyState = 0;
            */
            try {
                XMLDocument.prototype.readyState = 0;
            } catch(e) {
                // XXX on some browsers (Firefox 3.6 at least) this fails,
                // however I think this is rarely a problem so we just
                // ignore it here...
            };

            /**
            * <p>Emulate IE's parseError attribute</p>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.