Added API for checking if BASE_URI

[amartya4256]

The contribution provides an API to check if the location is the location where custom texts are loaded in a browser. By construct, "about:blank" is used for that purpose. This API can be adapted by the clients instead of explicitly defining the string and checking.

Contributes to #213

[github-actions[bot]]

Test Results

   486 files  ± 0     486 suites  ±0   8m 43s :stopwatch: + 1m 31s  4 156 tests + 5   4 148 :white_check_mark: + 5   8 :zzz: ±0  0 :x: ±0  16 378 runs  +20  16 286 :white_check_mark: +20  92 :zzz: ±0  0 :x: ±0 

Results for commit aa4988a7. ± Comparison against base commit d200d94e.

:recycle: This comment has been updated with latest results.

[amartya4256]

Seeing the implementation, I am wondering whether it would also be sufficient to just add a showsCustomText() method instead of the isLocationForCustomText(String) one. Then the functionality would be completely independent from the location and the browser handle the state of whether it shows custom text or some URI-based page completely internally and even better hide it from consumers. @amartya4256 Can you check whether that's possible?

Edit: Please also validate against the WebKit implementation. It seems to already have the about:blank page encoded as kind of a base URI internally. It also has some comments about using about:blank to be consistent with IE, so maybe there is also some further chance to align. I.e., a comment states:

https://github.com/eclipse-platform/eclipse.platform.swt/blob/97cf720f1a64c04de12998b8a50cf57c7189c5f8/bundles/org.eclipse.swt/Eclipse%20SWT%20WebKit/cocoa/org/eclipse/swt/browser/WebKit.java#L634-L637

using showsCustomText() won't be possible everywhere since there are Url comparison before the location of the browser has changed. For example in location listener in the changing method which executes before the location is actually changed. Another option was to cache the state type on setText but we don't know where we land with back and forward calls so it cannot be fully implemented. Moreover, I find the current method fine to accept a location as an argument. If you want to check something explictly, that can be passed, otherwise browser.getUrl() can be passed.

The Webkit implementation does make the behaviour consistent by exchanging the places in the API result with about:blank but I think that our implementattion takes thwe technicality away from the client and they dont have to hardcode about:blank anymore and they can leave his decision completely on the browser to tell if it is their custom text page.