Problem
The beforeload event fires when we click on links that link to anchors within the same currently loaded web page. No loading is occurring when we navigate within the same web page as the page is already loaded but the event still fires.
Code to reproduce
var webview = Ti.UI.createWebView({
height: Ti.UI.FILL,
width: Ti.UI.FILL,
url: 'https://raw.github.com/gist/22a51c5d42ebdf3e47f2/31858a3f1e119825497164fc03c4e47cd8fd0aef/bacon.html'
});
webview.addEventListener('beforeload', function(e){
alert('hi');
});
var win = Ti.UI.createWindow();
win.open();
win.add(webview);
Steps to reproduce
1. When the app starts 'beforeload' event is fired as expected.
2. Click on a link.
3. 'beforeload' event is fired.
Expected result
'beforeload' event is fired before the web view starts to load the web page contents. The event should not be fired when navigating within the page as the page is not reloaded.
This is due to Apple's [native implementation](https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIWebViewDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intf/UIWebViewDelegate). We could surpress this event, in fact I recall a pull for this, but the pull needed rewriting (It would accidentally surpress actual new page loads that happened to have a hash in it). I suppose the first question is how one determines if it's the same page, and does it surpress it for when you're intentionally reloading the page?
[2:56pm] srahim: bhamon: are you working on Timob-10157 ? [2:56pm] bhamon: You can grab it. I was poking about as to what defines a new load. [2:56pm] bhamon: Because having a hash does not necessarily mean it's not a load. [2:57pm] bhamon: For example, going from https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIWebViewDelegate_Protocol/Reference/Reference.html to https://developer.apple.com/library/ios/, despite it being just cropping off the #, IS a new load. [2:58pm] srahim: bhamon: hmmm. interesting. [2:59pm] srahim: bhamon: so is there even a possible solution for this ? [2:59pm] bhamon: Yeah. I should note that. [2:59pm] bhamon: Not sure. [2:59pm] bhamon: Too too easy to have a false negative and suppress a proper load. [2:59pm] srahim: bhamon: that is true. looking at edge cases for it can lead to lot of false negatives.
We fire the
beforeloadevent before a web view begins loading a frame. This happens regardless if you open a link or click on anchor to the same page and there is not much that can be done from the native side. As we fire of these events from the native webview delegate- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType;Trying to see if this load events are called from the same page would most probably lead to more false negatives and can cause regressions. For example the following url https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIWebViewDelegate_Protocol/Reference/Reference.html has a # tag indicating that it might be an anchor but if you try removing https://developer.apple.com/library/ios/ , would take you to diff page all together. The best option left would be for the developer to identify this in javascript using thebeforeLoadeventsnavigationTypeproperty, which gives info about the type of navigation that is being handled . navigationType would relate to : 0 - UIWebViewNavigationTypeLinkClicked, - User tapped a link. 1 - UIWebViewNavigationTypeFormSubmitted, - User submitted a form. 2 - UIWebViewNavigationTypeBackForward, - User tapped the back or forward button. 3 - UIWebViewNavigationTypeReload, - User tapped the reload button. 4 - UIWebViewNavigationTypeFormResubmitted, - User resubmitted a form. 5 - UIWebViewNavigationTypeOther - Some other action occurred. So marking this bug as invalid.Closing as invalid