Bug 28011

Summary: Javascript core in webkit seems not work under 2 "window.location" issued
Product: WebKit Reporter: AlbertYu <yu.tsunghua>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Critical CC: ahmad.saleem792, ap, bfulgham, rniwa, yu.tsunghua
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
Attachments:
Description Flags
A test web page for webkit none

AlbertYu
Reported 2009-08-04 20:25:51 PDT
Dear Webkit Experts: Right now we are using Linux x86 + qt embedded 4.5.2 to build a VOD client. The problem what we met is that if contiguous two "window.location=" be issued in a javascript code section, QT webkit moudle seems can't send out the first one window.location. in other word, the first window.location was overwrite by the second one. the first window.location is an RTSP URL. the second is an HTTP URL. we build a test enviroment to simulate the whole process. here is the followings. 1. for first page, just an index page. index.html <html> <head> </head> <body> <a href="http://192.168.11.5/darkmomo/rtsp.html">RTSP</a> </body> </html> 2. for second page, launch the rtsp url via javascript in body tag onload action. rtsp.html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=big5" > <title>RTSP URL Test</title> </head> <body topmargin="0" leftmargin="0" text="#FFFFFF" onload="playContent()" > <script language="javascript"> function playContent() { window.location="rtsp://192.168.11.5/"; onBack(); } function onBack() { window.location="http://192.168.11.5/show.html"; } </script> </body> </html> 3. for third page, just show the current program end. <html> <head> <title>In On Back Page</title> </head> <body> <a>Back Page</a> </body> </html> when we using the QWebView to test the three pages, we can't get the RTSP URL request via qt's way. and we got the trolltech's expert advise to seek webkit experts to find out a workaround way to address this problem. the trolltech's expert tell us the problem seems come from the webkit's javascript core. would any body to do us a favor to show us how to trace the window.location was be handled? we want to know where the window.location was be handled and add some debug message to see what is really happened. Thanks in advance. Best Regards, Albert
Attachments
A test web page for webkit (565 bytes, text/html)
2009-08-04 20:28 PDT, AlbertYu 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
AlbertYu
Comment 1 2009-08-04 20:28:05 PDT
Created attachment 34115 [details] A test web page for webkit
Ahmad Saleem
Comment 2 2022-07-21 13:26:05 PDT
I am not sure on Expected result but Safari 15.6 on macOS 12.5 is behaving different from other browsers and also I am not sure, whether it was Qt port specific bug or not. Using Safari 15.6 on macOS 12.5 with attached test case (in Private Window), it loads following dialog box showing 'Safari cannot open the page because the address is invalid.' (while no other browsers - Chrome Canary 105 and Firefox Nightly 104 show it). and later it change title to (....) and tries to load website, which takes ages while loading bar being stuck (eventually it resolve to following - http://192.168.11.5/darkmomo/show.html) Other browsers directly load (without dialog box) the test case into (....) title page and have their progress stuck for long time but later resolving to same URL as Safari 15.6. Since Safari 15.6 is showing dialog box while other browser does not, I think it is something different what Safari is doing and whether it is aligned with Web-Spec or not, I am not sure but web compatibility with others would be great unless if Safari is correct and they need to align. Thanks!
Alexey Proskuryakov
Comment 3 2022-07-22 10:51:13 PDT
I don't think that the attachment is supposed to work as a standalone test case. There were many changes in this area since 2009, and if there is something still wrong, finding that based on this report wouldn't be straightforward. I think that we should treat this report literally as a Qt port issue, and close because this port is gone.
Note You need to log in before you can comment on or make changes to this bug.