WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
228564
[macOS Catalina] Some feature preferences have wrong default values
https://bugs.webkit.org/show_bug.cgi?id=228564
Summary
[macOS Catalina] Some feature preferences have wrong default values
Peng Liu
Reported
2021-07-28 12:50:40 PDT
When the feature flags SPI is not available, some feature preferences' default values are wrong.
Attachments
Patch
(5.89 KB, patch)
2021-07-28 13:18 PDT
,
Peng Liu
no flags
Details
Formatted Diff
Diff
Revise the patch based on Tim's comment
(4.87 KB, patch)
2021-07-28 14:14 PDT
,
Peng Liu
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Peng Liu
Comment 1
2021-07-28 12:51:14 PDT
<
rdar://81177857
>
Peng Liu
Comment 2
2021-07-28 13:18:35 PDT
Created
attachment 434451
[details]
Patch
Tim Horton
Comment 3
2021-07-28 14:03:45 PDT
Comment on
attachment 434451
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=434451&action=review
> Source/WebKit/UIProcess/Launcher/mac/ProcessLauncherMac.mm:89 > +#if HAVE(SYSTEM_FEATURE_FLAGS) > static const bool runningBoardHandlesPriorities = isFeatureFlagEnabled("RB_full_manage_WK_jetsam"_s); > +#else > + const bool runningBoardHandlesPriorities = true; > +#endif
I don't think you need this change; RUNNINGBOARD_WEBKIT_PRIORITY_SUPPORT is only on on iOS-family platforms, where we don't backdeploy and thus SYSTEM_FEATURE_FLAGS is always true. (Also evidenced by the fact that it wasn't guarded before)
Peng Liu
Comment 4
2021-07-28 14:09:11 PDT
Comment on
attachment 434451
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=434451&action=review
>> Source/WebKit/UIProcess/Launcher/mac/ProcessLauncherMac.mm:89 >> +#endif > > I don't think you need this change; RUNNINGBOARD_WEBKIT_PRIORITY_SUPPORT is only on on iOS-family platforms, where we don't backdeploy and thus SYSTEM_FEATURE_FLAGS is always true. (Also evidenced by the fact that it wasn't guarded before)
Hmm, I was misled by the folder name (Mac/ProcessLauncherMac.mm). Maybe we should remove `RB_full_manage_WK_jetsam` from Webkit-macos.plist?
Tim Horton
Comment 5
2021-07-28 14:11:50 PDT
Comment on
attachment 434451
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=434451&action=review
>>> Source/WebKit/UIProcess/Launcher/mac/ProcessLauncherMac.mm:89 >>> +#endif >> >> I don't think you need this change; RUNNINGBOARD_WEBKIT_PRIORITY_SUPPORT is only on on iOS-family platforms, where we don't backdeploy and thus SYSTEM_FEATURE_FLAGS is always true. (Also evidenced by the fact that it wasn't guarded before) > > Hmm, I was misled by the folder name (Mac/ProcessLauncherMac.mm). > > Maybe we should remove `RB_full_manage_WK_jetsam` from Webkit-macos.plist?
A sad vestige of history (should say Cocoa). Yeah, we can remove it from the plist later, but in this patch we can just leave it alone.
Peng Liu
Comment 6
2021-07-28 14:14:42 PDT
Created
attachment 434465
[details]
Revise the patch based on Tim's comment
Tim Horton
Comment 7
2021-07-28 14:41:09 PDT
Comment on
attachment 434465
[details]
Revise the patch based on Tim's comment View in context:
https://bugs.webkit.org/attachment.cgi?id=434465&action=review
> Source/WebKit/Shared/WebPreferencesDefaultValues.cpp:295 > +#if PLATFORM(MAC) > + return true; > +#else > return false; > +#endif
Technically by the same logic you could just change these to return true instead of the PLATFORM(MAC), because we'll always have SYSTEM_FEATURE_FLAGS on iOS-family). But either way will behave the same.
EWS
Comment 8
2021-07-29 09:27:50 PDT
Committed
r280424
(
240064@main
): <
https://commits.webkit.org/240064@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 434465
[details]
.
Peng Liu
Comment 9
2021-07-29 09:49:48 PDT
The API test failures are tracked by
bug 228589
.
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