Bug 28011

Summary:

Javascript core in webkit seems not work under 2 "window.location" issued

Product:

WebKit

Reporter:

AlbertYu <yu.tsunghua>

Component:

JavaScriptCore

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED INVALID

Severity:

Critical

CC:

ahmad.saleem792, ap, bfulgham, rniwa, yu.tsunghua

Priority:

Version:

528+ (Nightly build)

Hardware:

OS:

Linux

Attachments:

Description	Flags
A test web page for webkit	none

Description AlbertYu 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

Comment 1 AlbertYu 2009-08-04 20:28:05 PDT

Created attachment 34115 [details]
A test web page for webkit

Comment 2 Ahmad Saleem 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!

Comment 3 Alexey Proskuryakov 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.