This repository has been archived by the owner on Apr 3, 2020. It is now read-only.
loadUrl always opens in new mobile browser(not in the app) #3975
Conversation
This file contains 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
…test codes. With "-Wsign-compare" build option, errors are found: error: comparison of integers of different signs: 'const unsigned long' and 'const int' [-Werror,-Wsign-compare] error: comparison of integers of different signs: 'const int' and 'const unsigned int' [-Werror,-Wsign-compare]
Eliminate comparisons between size_t and int, different signs in unittest code
Both Crosswalk and Chrome they place the en-US.pak into folder "locales" in build of Linux and windows. Potientially there is conflicts, so it's better to set Crosswalk's locale-path as "locales/xwalk". Add a "xwalk_resource_delegate" class which indicates the right locale pack file to load for Crosswalk.
Change locale path from "locales" to "locales/xwalk"
This reverts commit bfe53fd, which broke the Crosswalk Windows build: ``` ninja: error: 'locales/xwalk', needed by 'crosswalk_win.zip', missing and no known rule to make it ```
Revert "Change locale-path from "locales" to "locales/xwalk""
This reverts commit 9808ed4,, it caused the compatibility in shared mode. After refactor XWalkView, XWalkViewInternal and ContentViewRenderView need to be added to XWalkView concurrently. If the older XWalkView was used, ContentViewRenderView was not added, so leads to the black screen issue. BUG=XWALK-7217 BUG=XWALK-7100
…OverviewMode XWalk enable the wide viewport quirk in 2e9640b and implemented corresponding APIs in ebfc438, and the default values of mUseWideViewport and mLoadWithOverviewMode were set to false to keep the same with Android WebView. However, XWalk has the different usage in H5 game development, it no need to require developer set those valuse via APIs, and it's better to keep the same with Chromium instead of WebView, so set the default values to true will have benefit and convenience. BUG=XWALK-6995 BUG=XWALK-6963 BUG=XWALK-7051
Both Crosswalk and Chrome they place the en-US.pak into folder "locales" in build of Linux and windows. Potientially there is conflicts, so it's better to set Crosswalk's locale-path as "locales/xwalk". Add a "xwalk_resource_delegate" class which indicates the right locale pack file to load for Crosswalk.
Change locale-path from "locales" to "locales/xwalk"
Roll Chromium 52.0.2743.116
[Android] Refine the default values of mUseWideViewport and mLoadWith…
Revert "[Android] Refactor XWalkView to receive events directly."
…6995 Revert "[Android] Refine the default values of mUseWideViewport and mLoadWith…"
This DCHECK should have been removed in commit e1f52c3 ("Roll Chromium 50.0.2661.102") to adapt to https://codereview.chromium.org/1563633002: the upstream code was refactored and we need to follow the changes that were done to android_webview's version of this file, otherwise a debug build crashes at least whenever a media file is being played.
AndroidStreamReaderURLRequestJob: Remove leftover DCHECK.
Originally, XWalkView is designed to be tightly bound to the activity that creates and holds it, and to listen the state change and activity result, which will cause following problems: - With the change of the container activity's life cycle, XWalkView will pause all timers and other components like videos when activity paused, which is not suited to the usage in background. - Single XWalkView can't be shared across multiple activities. - XWalkView must be created in an activity, it can't be used for a service. - A XWalkView object will be destroyed after its container activity died and can't be used anymore. To solve the problems above, we decided to decouple XWalkView from the activity and give the developer more freedom to handle it. This patch does following things: - XWalkView can be created and held in any context, including a service. - XWalkInitializer and XWalkUpdate don't have to be created in an activity, they support to initialize Crosswalk environment in any context. - XWalkExternalExtensionManager doesn't handle the activity result anymore. - The implementation of the file chooser in XWalkView is separated to a individual class called XWalkFileChooser. Because it needs to receive an activity, it can't be integrated into internal library as default file chooser. So move it from org.xwalk.core.internal to org.xwalk.core as a new API, the developer has to invoke it manually in XWalkUIClient.openFileChooser. - Use the application context instead of the activity in XWalkPresentationHot and BuiltinXWalkExtensions to avoid memory leak. BUG=XWALK-7002
[Android] Decouple XWalkView from the activity
Update release notes for Crosswalk 20 stable
The onShow/HideCustomView() was implemented in Crosswalk by default and not exposed, it could not be overrided by customer to implement the video fullscreen. This patch is to expose onShow/HideCustomView(). BUG=XWALK-6939
Add assertions on holding the lock into getters called from native code. BUG=XWALK-5635
[Android] Reflection generator supports the @deprecated annotation
[Android]Fix thread unsafety in accessing Java side getters
CookieManger isn't used at starting crosswalk, so the datas need to be moved early. https://codereview.chromium.org/71583002 BUG=XWALK-7368
The developer who want to use presentation has to add the permission: <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/> BUG=XWALK-7270
Contrary to what one would expect, having a dependency on a shared library target such as `libxwalkcore` does not cause an action to be re-run whenever the aforementioned shared library changes -- the .ninja file only depends on the library's .TOC file, so the action is called only if the library's symbol list changes. In practice, this means rebuilding `libxwalkcore.so` would not cause `xwalk_core_library` and its respective AAR to be regenerated, leading to all sorts of problems. We work around the issue by adding `depfile`s to the GN actions, and then adding those native libraries (as well as some other files like the .js ones in xwalk_core_library) to them. GN can then use their contents and trigger the actions when the files there change (in addition to the ones regularly tracked by the build system). BUG=XWALK-7433
[Android] Use depfiles when generating projects and AARs
[Android] Make the presentation support the application context
[Android] Move user data to profile directory
This class is the equivalent of Android WebViewDatabase, but it only has two APIs, hasFormData and clearFormData, they allow developers to determine whether there is any saved data for web forms and to clear such data. BUG=XWALK-7057
Implement the XWalkViewDatabase
When this switch is added to the crosswalk command-line, a SpecialStoragePolicy is enabled which allows crosswalk to use the total free space available on the device, instead of Chromium's standard of 10% of available space. BUG=XWALK-7413
Implement --unlimited-storage switch for crosswalk
Chromium started enforcing some Certificate Transparency policies by default in M53, and refuses to load certain websites when the CT verification fails while establishing the TLS connection; this affected Crosswalk because we were using the default CT verifier and policy enforcer, but we did not add any of the logs approved by the Chromium project (see net/cert/ct_known_logs_static-inc.h). Instead of doing so, stop requiring websites to pass Chromium's Certificate Transparency checks altogether after getting some clarification from upstream. The biggest impediment to us following Chromium's policy is that Crosswalk's release cycle would need to match Chromium's very closely to avoid two risks: 1) Chromium approves new CT logs, they start being used in new certificates, Crosswalk does not recognize the new logs and refuses to load a website with a valid certificate. 2) Chromium disqualifies a CT log, while Crosswalk does not and can end up trusting a certificate that Chromium no longer trusts. Additionally, the aforementioned list of built-in logs that Chromium uses stops being recognized 70 days after the build date, which can lead our users to a false sense of security if they do not update their own apps with a more recent Crosswalk (which we might not even have released yet). See the discussion in https://crbug.com/669978 for more information. BUG=XWALK-7398
Exposes PostBinaryMessageToJS(byte[] data, ulong size) to the .net extension bridge. - Uses XW_MessagingInterface2 to return an ArrayBuffer to the Javascript client - Improves data transfer speed for large amounts of raw data, as translating from a string is slow in Javascript. BUG=XWALK-4615
Add binary data transfer from .net extensions, as per XWALK-4615.
Stop enforcing Certificate Transparency verification
…osswalk SQLite Databases that are created using the window.openDatabase with System WebVieware not accessible in Crosswalk, the databases need to be moved to Crosswalk profile directory. BUG=XWALK-7368 XWALK-4488
[Windows] Fix .net extension unittests
[Android] Preserve websql databases when migrating from webview to cr…
If building with DISABLE_BUNDLED_EXTENSIONS features will just be marked as experimental so they can be enabled via a command line option instead of completely disabling them
If building with DISABLE_BUNDLED_EXTENSIONS
|
This is not a bug tracker. Please ask your question in the crosswalk-help mailing list or file a bug in https://crosswalk-project.org/jira. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Hi,
Since version 20.50.533.12 i do not have the option to open links in the same window as before(version 19.49.514.5 and below).
I know that the load function is deprecated and now it is recommended to use loadUrl, but i do not know how to make it open in the same app window.
Here is what i tried:
xWalkWebView.load RESULT: opens in new mobile browser.
xWalkWebView.evaluateJavascript("window.open('"+url+"', '_blank','location=no');",null); RESULT: loads a white screen and it looks stuck.
xWalkWebView.evaluateJavascript("window.open('"+url+"','_self');",null); RESULT: opens in new mobile window
xWalkWebView.loadUrl(url); RESULT: opens in new mobile window.
The scenario: