-
Notifications
You must be signed in to change notification settings - Fork 844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wip] use CWVWebView embedder in iOS #24657
base: master
Are you sure you want to change the base?
Conversation
chromium_src/ios/web_view/internal/webui/web_view_web_ui_provider.mm
Outdated
Show resolved
Hide resolved
common_flags = [ "-fapplication-extension" ] | ||
cflags_objc = common_flags | ||
cflags_objcc = common_flags | ||
defines = [ "CWV_IMPLEMENTATION" ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be redefined for cwv_exports.h
to properly export the symbols since we're copying public headers as-is
9cf323a
to
0817eb4
Compare
if webView.fullscreenState == .inFullscreen || webView.fullscreenState == .enteringFullscreen { | ||
webView.closeAllMediaPresentations { | ||
self.present(alertController, animated: true) | ||
} | ||
return | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is done by chromium already https://source.chromium.org/chromium/chromium/src/+/main:ios/web/web_state/ui/crw_wk_ui_handler.mm;l=124
6ccffe6
to
66895b3
Compare
|
||
- (CWVReuseCheckService*)reuseCheckService { | ||
- if (!_reuseCheckService && self.persistent) { | ||
- affiliations::AffiliationService* affiliation_service = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this AffiliationService seems concerning in general, I asked @ShivanKaul and @pes10k about it because it looks like something we might want to just replace with a no-op implemenation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now I don't compile any of the actual affiliation services (I just dont include them in the //brave/ios/web_view
target) which is why this implementation is patched out and would return nil always. We'd likely go the route of compiling //ios/web_view
as is though before landing this and no-op them with chromium_src overrides
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks like this is something to do with credential sharing with apps, but we already disable it by disabling the fetch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was the reason this was commented out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its commented out because we dont compile the necessary files for it atm (just //ios/web_view/internal/affiliations/web_view_affiliation_service_factory.h/mm
at this point)
ApplicationContext::~ApplicationContext() = default; | ||
|
||
PrefService* ApplicationContext::GetLocalState() { | ||
return GetApplicationContext()->GetLocalState(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks a layering violation because I don't think ios/web_view
is supposed to access ios/chrome/browser, but I'm a bit confused about why it has a separate ApplicationContext
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed in DM but will reiterate here anyways: ios/web_view
basically has a whole "app" setup (custom ApplicationContext, custom WebClient, custom factories) because its completely independent from //ios/chrome
. This isn't really helpful for us though because we already have the Chrome app setup in place, so we basically have to replace all of ios/web_view
s implementations with the Chrome ones. This may need better overrides to avoid layering violations though
] | ||
} | ||
|
||
source_set("web_view") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why are we adding these here instead of using web_view_sources
, etc...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was originally to control what was compiled, the hope is to be able to eventually just use //ios/web_view:web_view_sources
directly as more chromium_src overrides + patches are added
ios/web_view/web_view_sources.gni
Outdated
|
||
# This file exposes the //ios/web_view embedder as a regular source_set | ||
|
||
ios_web_view_public_headers = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this different from ios_web_view_public_headers
in ios/web_view/BUILD.gn
? If so it would be better to use +=
/-=
instead of duplicating
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The parts under our own 1 extra public header aren't different but since the original list is defined in a GN file and not GNI I couldn't access them to add into our framework so for now it was duped. If its possible to get to let me know!
4be9903
to
0231609
Compare
042c989
to
39840e8
Compare
88bbb98
to
95bc4df
Compare
the underlying WebState needs to be associated with the Browser/WebStateList and be assigned a SessionID from the Browser so for now we'll go back to using the fake WebState to handle this. For FaviconDriver we can use WebFaviconDriver in the future but need to add an observer to Swift side to update Tab.favicon properly
This change removes a majority of underlying web view access which would create the web view too early for `target=_blank` style links and hit an assertion in WebKit
this should instead be patched/overridden at the service/factory level, we wont use this variable on CWVWebViewConfiguration either way
this is already handled by Chromium
rewrites `chrome` schemes to `brave` when formatting and loads them as standard requests
f284118
to
f851327
Compare
Do not merge, meant for gathering feedback on this solution's direction
Running list:
Needs Migration
WKWebView.interactionState
, need to drop it or ignore it while restoringCWVWebView
and vice-versa.Broken Features
getInternalRedirect
, loading a new request before cancelling an active load) on pages that fail to load in the end hit DCHECK (e.g.http://api.segment.io
will get upgraded tohttps
but the link itself is blocked by PiHole/content blockers)Cosmetic Issues
Product Changes
Accesses WebKit
These access
-[CWVWebView(Extras) underlyingWebView]
or-[CWVWebView(Extras) WKConfiguration]
directly and should be migrated over if possibleFontSizeTabHelper
as a replacement but it's worseloadHTMLString
), only exposed for testing in ChromiumCleanup
CWVWebView
New Feature Support
Security Checklist
TBD