Repository navigation
GH-359: Fix beforeload to work with POST requests - #367
Merged
Merged
Conversation
…beforeload. For now only GET is supported with beforeload, so document this.
|
Any updates on getting this PR merged? @janpio |
Member
|
Feel free to test it and describe how and what you did, then leave a pull request review in the "Files changed" tab reflecting your results. (But please don't @ mention people here that were not active in a issue or pull request before - if everyone did that I would get even less work done each day...) |
|
You where active in the issue that this pr addresses... #359. In which i tested and left a comment that its working as correctly as architected in the issue thread... |
Contributor
Author
|
@janpio Anything more needed here or can this be merged? |
Member
|
Nah, all good. |
Contributor
Author
|
😎 nice one |
3 tasks done
EYALIN
pushed a commit
to EYALIN/community-cordova-plugin-inappbrowser
that referenced
this pull request
May 23, 2026
### Platforms affected iOS and Android ### What does this PR do? Fixes the behaviour of `beforeload` to resolve the problem with POST requests outlined in apache#359. The `beforeload` parameter has been changed from taking only a boolean (`yes` or not defined) to a discrete string with possible values of `get`, `post`, or `yes` which correspond to request types of GET, POST or GET&POST respectively. The `README.md` has been updated to reflect this. Note that use of `beforeload` to intercept POST requests is currently not supported on Android or iOS, so if `beforeload=yes` is specified and a POST request is detected as the HTTP request method, `beforeload` behaviour will not be applied. If `beforeload=post` is specified, a `loaderror` event will be dispatched which states that POST requests are not yet supported. #### Notes for Android The `shouldOverrideUrlLoading()` override method has been updated to support the [new method interface added in API 24 / Android 7][1] which receives the `WebResourceRequest` instead of just the `String url`, enabling the HTTP method of the request to be determined. The [deprecated method interface][2] has also been preserved for API <=23, but in this case the HTTP method cannot be determined so is passed as null. Also note that due to a [Chromium bug](https://bugs.chromium.org/p/chromium/issues/detail?id=155250), `shouldOverrideUrlLoading()` is currently not called for POST requests. It's possible this may be resolved in a future Chromium version in the Android System Webview (given that this is now self-updating and independent of Android version since Android 5.0) - in prospective anticipation of this, code to handle POST requests has been added to `shouldOverrideUrlLoading()`. However, it seems more likely that this won't be resolved any time soon given that [a Chromium dev said](https://bugs.chromium.org/p/chromium/issues/detail?id=155250#c39): > We're looking at implementing a better way to handle request interception in a future OS version. There's no way to just "fix" this, the API doesn't accommodate this usage at all. This will not be something you can use any time soon. Therefore if we want to go ahead and use `beforeload` to intercept request types other than GET, it's likely we'll instead need to use the `shouldInterceptRequest()` method override. As with `shouldOverrideUrlLoading()`, there are a two variants: the [new method interface][3] added in API 21 / Android 5.0 which which receives the `WebResourceRequest` object and the [deprecated one][4] which receives only `String url`. If we want to determine the HTTP request method, we'll need to use the new implementation. This has been empirically tested and *is* called for POST requests so would allow the possibility to intercept, delay, modify and send the POST request and its data via `beforeload`. Both `shouldInterceptRequest()` method interfaces have been exposed in the Android implentation for potential future use but they currently do nothing other than return the unadulterated request object. ### What testing has been done on this change? Manual testing of POST and GET requests on both platforms using a test app container: https://github.com/dpa99c/cordova-plugin-inappbrowser-test [1]: https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldOverrideUrlLoading(android.webkit.WebView,%20android.webkit.WebResourceRequest) [2]: https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldOverrideUrlLoading(android.webkit.WebView,%20java.lang.String) [3]: https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldInterceptRequest(android.webkit.WebView,%20android.webkit.WebResourceRequest) [4]: https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldInterceptRequest(android.webkit.WebView,%20java.lang.String)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Platforms affected
iOS and Android
What does this PR do?
Fixes the behaviour of
beforeloadto resolve the problem with POST requests outlined in #359.The
beforeloadparameter has been changed from taking only a boolean (yesor not defined) to a discrete string with possible values ofget,post, oryeswhich correspond to request types of GET, POST or GET&POST respectively. TheREADME.mdhas been updated to reflect this.Note that use of
beforeloadto intercept POST requests is currently not supported on Android or iOS, so ifbeforeload=yesis specified and a POST request is detected as the HTTP request method,beforeloadbehaviour will not be applied. Ifbeforeload=postis specified, aloaderrorevent will be dispatched which states that POST requests are not yet supported.Notes for Android
The
shouldOverrideUrlLoading()override method has been updated to support the new method interface added in API 24 / Android 7 which receives theWebResourceRequestinstead of just theString url, enabling the HTTP method of the request to be determined. The deprecated method interface has also been preserved for API <=23, but in this case the HTTP method cannot be determined so is passed as null.Also note that due to a Chromium bug,
shouldOverrideUrlLoading()is currently not called for POST requests. It's possible this may be resolved in a future Chromium version in the Android System Webview (given that this is now self-updating and independent of Android version since Android 5.0) - in prospective anticipation of this, code to handle POST requests has been added toshouldOverrideUrlLoading().However, it seems more likely that this won't be resolved any time soon given that a Chromium dev said:
Therefore if we want to go ahead and use
beforeloadto intercept request types other than GET, it's likely we'll instead need to use theshouldInterceptRequest()method override. As withshouldOverrideUrlLoading(), there are a two variants: the new method interface added in API 21 / Android 5.0 which which receives theWebResourceRequestobject and the deprecated one which receives onlyString url. If we want to determine the HTTP request method, we'll need to use the new implementation. This has been empirically tested and is called for POST requests so would allow the possibility to intercept, delay, modify and send the POST request and its data viabeforeload.Both
shouldInterceptRequest()method interfaces have been exposed in the Android implentation for potential future use but they currently do nothing other than return the unadulterated request object.What testing has been done on this change?
Manual testing of POST and GET requests on both platforms using a test app container:
https://github.com/dpa99c/cordova-plugin-inappbrowser-test