WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
131921
[iOS] runtime application checks don't work in WebKit2
https://bugs.webkit.org/show_bug.cgi?id=131921
Summary
[iOS] runtime application checks don't work in WebKit2
Eric Carlson
Reported
2014-04-20 16:10:38 PDT
The various application checks in RuntimeApplicationChecksIOS.cpp don't work as expected when running in WebKit2 because they assume [[NSBundle mainBundle] bundleIdentifier] returns the bundle ID of the host application.
Attachments
Proposed patch.
(11.00 KB, patch)
2014-04-20 17:24 PDT
,
Eric Carlson
sam
: review-
Details
Formatted Diff
Diff
Updated patch
(11.15 KB, patch)
2014-04-20 17:34 PDT
,
Eric Carlson
no flags
Details
Formatted Diff
Diff
Updated patch
(11.61 KB, text/plain)
2014-04-20 21:57 PDT
,
Eric Carlson
no flags
Details
Updated patch
(11.57 KB, patch)
2014-04-20 22:05 PDT
,
Eric Carlson
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Eric Carlson
Comment 1
2014-04-20 16:11:34 PDT
<
rdar://16565372
>
Radar WebKit Bug Importer
Comment 2
2014-04-20 16:12:18 PDT
<
rdar://problem/16671610
>
Eric Carlson
Comment 3
2014-04-20 17:24:17 PDT
Created
attachment 229777
[details]
Proposed patch.
WebKit Commit Bot
Comment 4
2014-04-20 17:26:32 PDT
Attachment 229777
[details]
did not pass style-queue: ERROR: Source/WebKit2/ChangeLog:1: ChangeLog entry has no bug number [changelog/bugnumber] [5] ERROR: Source/WebKit/mac/ChangeLog:1: ChangeLog entry has no bug number [changelog/bugnumber] [5] Total errors found: 2 in 9 files If any of these errors are false positives, please file a bug against check-webkit-style.
Sam Weinig
Comment 5
2014-04-20 17:32:01 PDT
Comment on
attachment 229777
[details]
Proposed patch. View in context:
https://bugs.webkit.org/attachment.cgi?id=229777&action=review
> Source/WebCore/page/Settings.h:275 > + static void setEmbeddingApplicationBundleID(const String&); > + static const String& embeddingApplicationBundleID();
These don't seem like Settings things. Why don't we just put all this in RuntimeApplicationChecks.h/mm.
Eric Carlson
Comment 6
2014-04-20 17:34:04 PDT
Created
attachment 229778
[details]
Updated patch
Darin Adler
Comment 7
2014-04-20 20:42:20 PDT
Comment on
attachment 229778
[details]
Updated patch View in context:
https://bugs.webkit.org/attachment.cgi?id=229778&action=review
> Source/WebCore/page/Settings.h:275 > + static void setEmbeddingApplicationBundleID(const String&); > + static const String& embeddingApplicationBundleID();
Never sure if such things belong in Settings, but I guess it’s OK.
> Source/WebKit/mac/WebView/WebView.mm:2458 > + settings.setEmbeddingApplicationBundleID(String([[NSBundle mainBundle] bundleIdentifier]));
I don’t think the explicit String() is needed here. Is it?
Eric Carlson
Comment 8
2014-04-20 21:57:02 PDT
Created
attachment 229783
[details]
Updated patch
Eric Carlson
Comment 9
2014-04-20 22:04:13 PDT
(In reply to
comment #7
)
> (From update of
attachment 229778
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=229778&action=review
> > > Source/WebCore/page/Settings.h:275 > > + static void setEmbeddingApplicationBundleID(const String&); > > + static const String& embeddingApplicationBundleID(); > > Never sure if such things belong in Settings, but I guess it’s OK. > > > Source/WebKit/mac/WebView/WebView.mm:2458 > > + settings.setEmbeddingApplicationBundleID(String([[NSBundle mainBundle] bundleIdentifier])); > > I don’t think the explicit String() is needed here. Is it?
Oops you are right. I copied that from WebKit2 without thinking about whether or not it was necessary.
Eric Carlson
Comment 10
2014-04-20 22:05:14 PDT
Created
attachment 229784
[details]
Updated patch
mitz
Comment 11
2014-04-20 22:10:34 PDT
I don’t understand why this is a bug, and I think the proposed fix (whatever it’s fixing) is conceptually wrong. Of all the apps being tested for, none currently use the WebKit2 API. On what basis are we customizing behavior for apps that aren’t even clients of the framework? Future adopters of the API should get the API’s standard behavior. If that blocks adoption, they can request whatever additional API they need. If we anticipate such needs, we should provide such API.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug