Ticket #29 (new defect)

Opened 1 year ago

Last modified 6 months ago

URL Lib: broken in Opera 9.2

Reported by: guest Assigned to: Jan-Klaas Kollhof
Priority: high Milestone:
Component: jsolait-core Version: 2.0
Severity: normal Keywords: opera urllib
Cc:

Description

Recently Opera released version 9.20 which broke URL Lib behavior.

Sample Error Console output: 

JavaScript - http://myHost/myPath/myPage.html
Unknown thread
Error:
name: TypeError
message: Statement on line 247: Could not convert undefined or null to object
Backtrace:
  Line 247 of linked script http://myHost/myPath/jsolait/lib/urllib.js
    if (xmlhttp.readyState == 4)
    else
      At unknown location
    [statement source code not available]

Not yet sure if this issue resides in Opera or jsolait (requires further investigation) but I guess it's better to have this issue documented, even if it's an Opera issue, so users can know about it.

Regards,

Helder Magalhães

Attachments

UrlLib-XmlHttpRequestFixForRecentOperaReleases.patch (2.0 kB) - added by heldermagalhaes on 04/18/08 11:58:24.
Patch which fixes the issue.

Change History

12/13/07 16:36:58 changed by heldermagalhaes

It's relevant to state that this happens only when using assyncronous requests. For example, jsolait's syncronous samples (try any of the presets) work fine, while the assyncronous sample is broken in Opera versions above 9.10 (last known working version).

Recently tested with newest 9.50 beta (codename Kestrel), which unfortunately showed the same results.

In Opera, errors can be seen in Tools/Advanced/Error Console.

(follow-up: ↓ 4 ) 02/22/08 09:09:45 changed by guest

the actual problem is here: try{ var s=xmlhttp.status; }catch(e){ callback(xmlhttp); xmlhttp=null; } You try reading .status when readyState is 2. We throw because at some point in time I figured out that was what IE7 and Firefox both do when the request is at this stage. Seems they don't, or do it in only one of the modes (async/sync)? In any case, if you don't reset xmlhttp to null here it works.

02/22/08 09:10:49 changed by guest

(Sorry I should have signed that comment properly since I'm logged in with a rather anonymous "guest" account. Previous comment was made by Hallvord R. M. Steen, Core QA tester at Opera Software.)

04/18/08 11:58:24 changed by heldermagalhaes

  • attachment UrlLib-XmlHttpRequestFixForRecentOperaReleases.patch added.

Patch which fixes the issue.

(in reply to: ↑ 2 ) 04/18/08 12:10:00 changed by heldermagalhaes

Replying to Hallvord Steen:

In any case, if you don't reset xmlhttp to null here it works.

Thanks for your contribution. Unfortunately I didn't realized you had comment on this, so the patch was created independently from it - although it makes exactly what you have suggested! :-)

I decided to treat Opera differently while addressing the "set to null" issue. Maybe Internet Explorer was the one which should be treated differently but...

  • Using document.all could bring unexpected behavior due to recent nightly builds cloaking approach;
  • This was the simplest change to make it work again - tested with IE 6 and 7, Opera 9.2x and 9.5 beta, Firefox 2 and 3 beta, Safari 3, 3.1 and Webkit nightly builds and Batik 1.7. ;-)