[
https://issues.apache.org/jira/browse/CB-14188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16546557#comment-16546557
]
ASF GitHub Bot commented on CB-14188:
-------------------------------------
brodybits commented on issue #276: CB-14188: add beforeload event, catching
navigation before it happens
URL:
https://github.com/apache/cordova-plugin-inappbrowser/pull/276#issuecomment-405571972
Looks nice in general. A couple major comments on my part:
The idea of passing an asynchronous callback to an event listener seems
really strange to me. While I can definitely understand the logic behind making
it asynchronous between native and JavaScript I don't think this really
justifies introducing what looks like new paradigm in event listeners. I can
think of the following alternative approaches:
- event listener *synchronously* returns non-null value to indicate that
application does not want to load the URL, in a similar fashion to a standard
`beforeload` event handler ref:
[[1]](https://eloquentjavascript.net/15_event.html#p_nu8/BUQa7r) (preferred)
- event listener throws an exception to override default behavior, in a
similar fashion to `backbutton` event on Windows ref:
[[2]](https://cordova.apache.org/docs/en/latest/cordova/events/events.html#windows-quirks)
- new asynchronous callback mechanism *outside* the event handler mechanism
that the application can use to filter URL load requests
The code also seems to assume that there would never be multiple outstanding
load requests, which I would not agree with. What if a user clicks on a couple
links in succession, or the webpage JavaScript issues multiple HTTP(S) requests?
[1] <https://eloquentjavascript.net/15_event.html#p_nu8/BUQa7r>
[2]
<https://cordova.apache.org/docs/en/latest/cordova/events/events.html#windows-quirks>
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Callback to decide whether to open link or not.
> -----------------------------------------------
>
> Key: CB-14188
> URL: https://issues.apache.org/jira/browse/CB-14188
> Project: Apache Cordova
> Issue Type: New Feature
> Components: cordova-plugin-inappbrowser
> Affects Versions: 3.0.0
> Reporter: wvengen
> Priority: Major
>
> Several times I've found myself wanting to tell inAppBrowser whether it can
> open a link in the embedded webview or using the system web browser. It would
> be great if there's a callback _before_ loading a page (loadstart is too late
> there), where I can tell inAppBrowser to load the page or not.
> CB-14013 introduced AllowedSchemes, but excluded the use of http and https.
> -It would be useful to allow intercepting http and https links, e.g. to
> decide whether to open the link in the system web browser or not.- At first I
> thought this mechanism could be used, but because of the asynchronous nature
> of Cordova callbacks, this didn't work out, and I added a beforeload
> callback. See comment for an example.
> I've submitted a PR -(my approach would be to generate a regexp based on
> AllowedSchemes and match the URL on that, instead of the current if logic)-.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
