[Webkit-unassigned] [Bug 165627] itunes app links fail to navigate window.top when URL inside timeout

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=165627

--- Comment #5 from Frédéric Wang (:fredw) <fred.wang at free.fr> ---
So trying to debug on the simulator, "window.top.location.href = 'https://itunes.apple.com/us/app/id828256236'" triggers the following backtrace on the Web process:

#0 WebCore::NavigationScheduler::startTimer()
#1 WebCore::NavigationScheduler::schedule
#2 WebCore::NavigationScheduler::scheduleLocationChange
#3 WebCore::DOMWindow::setLocation
#4 WebCore::Location::setLocation
#5 WebCore::Location::setHref

Which in turn schedules a load to 'https://itunes.apple.com/us/app/id828256236':

#0 WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction
#1 WebCore::PolicyChecker::checkNavigationPolicy
#2 WebCore::FrameLoader::loadWithDocumentLoader
#3 WebCore::FrameLoader::loadWithNavigationAction
#4 WebCore::FrameLoader::loadURL
#5 WebCore::FrameLoader::loadFrameRequest
#6 WebCore::FrameLoader::urlSelected
#7 WebCore::FrameLoader::changeLocation
#8 WebCore::ScheduledLocationChange::fire
#9 WebCore::NavigationScheduler::timerFired()

As said in comment 3, the issue is a bit difficult to reproduce on the simulator, but when the message "Safari cannot open the page because the address is invalid" does show up, I actually later see a request to 'itmss://itunes.apple.com/us/app/id828256236':

#0 WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction
#1 WebCore::PolicyChecker::checkNavigationPolicy
#2 WebCore::PolicyChecker::checkNavigationPolicy
#3 WebCore::DocumentLoader::willSendRequest
#4 WebCore::DocumentLoader::redirectReceived
#5 WebCore::iterateClients
#6 WebCore::CachedRawResource::redirectReceived
#7 WebCore::SubresourceLoader::willSendRequestInternal
#8 WebCore::ResourceLoader::willSendRequest
#9 WebKit::WebResourceLoader::willSendRequest

Debugging the network process, the redirection from 'https://' to 'itmss://' protocol actually passes here: 

#0 WebKit::NetworkResourceLoader::continueWillSendRedirectedRequest
#1 WebKit::NetworkResourceLoader::willSendRedirectedRequest
#2 WebKit::NetworkLoad::willPerformHTTPRedirection
#3 WebKit::NetworkDataTaskCocoa::willPerformHTTPRedirection
#4 ::-[WKNetworkSessionDelegate URLSession:task:willPerformHTTPRedirection:newRequest:completionHandler:](NSURLSession *, NSURLSessionTask *, NSHTTPURLResponse *, NSURLRequest *, void (^)(NSURLRequest *))

I could not find out from where willPerformHTTPRedirection is called and hence where the protocol changes actually happens though.

I noticed that opening directly the 'itmss://' URL on the simulator does result in the "Safari cannot open the page because the address is invalid" alert showing up, so that would explain what I see on the simulator. Not sure if that's the same issue on a device.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180427/320147a4/attachment-0001.html>