Summary: | [Qt][Symbian] Hang : No response on calling send() method on XMLHttpRequest object. | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | vijaysharma <murlivala> | ||||
Component: | Platform | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED INVALID | ||||||
Severity: | Blocker | CC: | benjamin, joel.parks, johannes.oikarinen, koshuin, krithigassree.sambamurthy, laszlo.gombos, markus, murali.alluri, peter.hartmann | ||||
Priority: | P1 | Keywords: | Qt, QtTriaged | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | S60 Hardware | ||||||
OS: | Other | ||||||
Attachments: |
|
Description
vijaysharma
2011-03-28 06:17:15 PDT
Hi, can we get the attachment you are talking about? Which version of QtWebkit, on which device, with which version of Qt ? What kind of test application? What kind of access point we are talking about? Is it behind firewall? etc.. XMLHttpRequest works, a lot of problems reported relate to wrong security settings. So to reproduce this issue we need more information. Created attachment 87276 [details]
Sample html to reproduce the issue
(In reply to comment #1) > Hi, can we get the attachment you are talking about? > Which version of QtWebkit, on which device, with which version of Qt ? What kind of test application? What kind of access point we are talking about? Is it behind firewall? etc.. > > XMLHttpRequest works, a lot of problems reported relate to wrong security settings. So to reproduce this issue we need more information. Qtwebkit version: qtwebkit 2.1.1 week 09 On device, keep the single access point(GPRS or WiFi) test html page has been attached already no firewall settings also ref WRT 7797; blocking WRT BAT since March 31 Can someone from Webkit team please prioritize this error. This is blocking WRT BAT. (In reply to comment #5) > Can someone from Webkit team please prioritize this error. This is blocking WRT BAT. It is already a P1-blocker. If you need it immediately, you should find someone who can look at the bug. The root cause of this issue is found in QtNetwork QNetworkReplyImpPrivate class. The class doesn't maintain correct state for synchronous requests; synchronous requests are set to finished already at the beginning of the request. Wrong state blocks the QNetworkReply from emitting finished signal when the request actually completes. Since no signal is emitted an eventloop in ResourceHandle::loadResourceSynchronously hangs at Webkit’s side. Webkit might need to have an additional check to see if the QNetworkReply contains any unread data before closing it. This is needed since a response can be received from a remote host before Webkit connects handlers for the QNetworkReply. QNetworkReplyHandler::finish could be suitable place to implement this. ref QT-5061 The sample html provided here shows the XML 101 Error across all browsers. (Chrome, Safari, Firefox and QtTestBrowser). Tried the original test (part of widget) in the Qt-5061. Unable to reproduce on QtTestBrowser (based on Qt 4.7) The sample html provided here shows the XML 101 Error across all browsers. (Chrome, Safari, Firefox and QtTestBrowser). Tried the original test (part of widget) in the Qt-5061. Unable to reproduce on QtTestBrowser (based on Qt 4.7) === 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. |