WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
184353
Use the system's link color when system appearance is desired for a WebView
https://bugs.webkit.org/show_bug.cgi?id=184353
Summary
Use the system's link color when system appearance is desired for a WebView
Timothy Hatcher
Reported
2018-04-05 20:38:47 PDT
The link color does not match the system, when the system appearance is desired. We should be using [NSColor linkColor]. <
rdar://problem/9420053
>
Attachments
Patch
(21.96 KB, patch)
2018-04-05 20:48 PDT
,
Timothy Hatcher
no flags
Details
Formatted Diff
Diff
Patch
(24.83 KB, patch)
2018-04-05 22:08 PDT
,
Timothy Hatcher
no flags
Details
Formatted Diff
Diff
Archive of layout-test-results from ews124 for ios-simulator-wk2
(2.67 MB, application/zip)
2018-04-05 23:42 PDT
,
EWS Watchlist
no flags
Details
Patch
(25.34 KB, patch)
2018-04-06 11:51 PDT
,
Timothy Hatcher
no flags
Details
Formatted Diff
Diff
Patch
(36.92 KB, patch)
2018-04-06 23:18 PDT
,
Timothy Hatcher
no flags
Details
Formatted Diff
Diff
Patch
(36.95 KB, patch)
2018-04-06 23:43 PDT
,
Timothy Hatcher
no flags
Details
Formatted Diff
Diff
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
Timothy Hatcher
Comment 1
2018-04-05 20:48:52 PDT
Created
attachment 337338
[details]
Patch
Timothy Hatcher
Comment 2
2018-04-05 22:08:12 PDT
Created
attachment 337346
[details]
Patch
EWS Watchlist
Comment 3
2018-04-05 23:42:23 PDT
Comment on
attachment 337346
[details]
Patch
Attachment 337346
[details]
did not pass ios-sim-ews (ios-simulator-wk2): Output:
http://webkit-queues.webkit.org/results/7223433
New failing tests: css3/selectors3/xml/css3-modsel-61.xml tables/mozilla/bugs/
bug46623
-1.html tables/mozilla/bugs/
bug8950
.html css3/selectors3/html/css3-modsel-17.html fast/selectors/017.html fast/dom/34176.html fast/selectors/061.html css3/selectors3/html/css3-modsel-61.html css3/selectors3/xhtml/css3-modsel-61.xml css3/selectors3/xhtml/css3-modsel-17.xml fast/css/style-tag-display-none.html tables/mozilla/bugs/
bug51140
.html css3/selectors3/xml/css3-modsel-17.xml
EWS Watchlist
Comment 4
2018-04-05 23:42:24 PDT
Created
attachment 337347
[details]
Archive of layout-test-results from ews124 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews124 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.4
Timothy Hatcher
Comment 5
2018-04-06 11:51:15 PDT
Created
attachment 337380
[details]
Patch
Megan Gardner
Comment 6
2018-04-06 19:03:06 PDT
Comment on
attachment 337380
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=337380&action=review
r=me, with my comments, except that I can't actually review, so you'll need someone else to get a real review from.
> Source/WebCore/css/StyleResolver.cpp:1841 > + options |= StyleColor::Options::UseSystemAppearance;
The above three lines are in many places. Could you consolidate it into a constructor for StyleColor::Options?
> Source/WebCore/rendering/RenderThemeMac.mm:447 > + // FIXME: Use a semantic system color for this, instead of systemPurpleColor.
File a radar for this FIXME, also is there a reason you're using systemPurpleColor rather than the one that was in Document?
> Source/WebCore/rendering/RenderThemeMac.mm:463 > + return useSystemAppearance ? @selector(linkColor) : nullptr;
Why don't we always want to use the link color from NSColor? It seems like we would, for consistency.
> Source/WebCore/rendering/RenderThemeMac.mm:466 > + // FIXME: Use a semantic system color for this, instead of systemRedColor.
Radar for this FIXME. Also, not sure if we want to do something different for if we are following system appearance or not.
Wenson Hsieh
Comment 7
2018-04-06 19:24:51 PDT
Comment on
attachment 337380
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=337380&action=review
> Source/WebCore/ChangeLog:4 > +
Nit - extra newline here.
> Source/WebCore/ChangeLog:8 > + Have Document consult RenderTheme via StyleColor for the various link colors.
Nit - the description should go after the Reviewed by line.
> Source/WebCore/PAL/ChangeLog:3 > + Use the system's link color when system appearance is desired for a WebView.
Could we write an API test for this? I imagine we could do something like: 1. Swizzle out +[NSColor linkColor] 2. Load an HTML string with a link 3. Evaluate JavaScript to query the computed style of the link There are helpers to make (2) and (3) more convenient if you create a TestWKWebView, and (1) can be accomplished via ClassMethodSwizzler (also see TestWebKitAPI).
> Source/WebCore/WebCore.xcodeproj/project.pbxproj:2609 > + 9418278B1D8B244000492764 /* StyleColor.h in Headers */ = {isa = PBXBuildFile; fileRef = 941827891D8B242200492764 /* StyleColor.h */; settings = {ATTRIBUTES = (Private, ); }; };
I think I might've missed something here, but is there a reason StyleColor.h needs to become private? I don't see StyleColor.h being included anywhere outside of WebCore.
Timothy Hatcher
Comment 8
2018-04-06 20:48:36 PDT
(In reply to Megan Gardner from
comment #6
)
> Comment on
attachment 337380
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=337380&action=review
> > r=me, with my comments, except that I can't actually review, so you'll need > someone else to get a real review from. > > > Source/WebCore/css/StyleResolver.cpp:1841 > > + options |= StyleColor::Options::UseSystemAppearance; > > The above three lines are in many places. Could you consolidate it into a > constructor for StyleColor::Options?
I agree. I'll see if I can clean this up.
> > Source/WebCore/rendering/RenderThemeMac.mm:447 > > + // FIXME: Use a semantic system color for this, instead of systemPurpleColor. > > File a radar for this FIXME, also is there a reason you're using > systemPurpleColor rather than the one that was in Document?
HI said we should use systemPurpleColor. I'll add the Radar for this fixme.
> > Source/WebCore/rendering/RenderThemeMac.mm:463 > > + return useSystemAppearance ? @selector(linkColor) : nullptr; > > Why don't we always want to use the link color from NSColor? It seems like > we would, for consistency.
The main reason is that the colors in Document are from the HTML spec, so it is consistent cross-browser to keep the old ones for web content.
> > Source/WebCore/rendering/RenderThemeMac.mm:466 > > + // FIXME: Use a semantic system color for this, instead of systemRedColor. > > Radar for this FIXME. Also, not sure if we want to do something different > for if we are following system appearance or not.
HI said we should use systemRedColor, but we will likely do something else for active. I'll add the Radar for this fixme.
Timothy Hatcher
Comment 9
2018-04-06 20:50:00 PDT
(In reply to Wenson Hsieh from
comment #7
)
> Comment on
attachment 337380
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=337380&action=review
> > > Source/WebCore/ChangeLog:4 > > + > > Nit - extra newline here. > > > Source/WebCore/ChangeLog:8 > > + Have Document consult RenderTheme via StyleColor for the various link colors. > > Nit - the description should go after the Reviewed by line. > > > Source/WebCore/PAL/ChangeLog:3 > > + Use the system's link color when system appearance is desired for a WebView. > > Could we write an API test for this? I imagine we could do something like: > > 1. Swizzle out +[NSColor linkColor] > 2. Load an HTML string with a link > 3. Evaluate JavaScript to query the computed style of the link > > There are helpers to make (2) and (3) more convenient if you create a > TestWKWebView, and (1) can be accomplished via ClassMethodSwizzler (also see > TestWebKitAPI).
Okay. I'll give that a try.
> > Source/WebCore/WebCore.xcodeproj/project.pbxproj:2609 > > + 9418278B1D8B244000492764 /* StyleColor.h in Headers */ = {isa = PBXBuildFile; fileRef = 941827891D8B242200492764 /* StyleColor.h */; settings = {ATTRIBUTES = (Private, ); }; }; > > I think I might've missed something here, but is there a reason StyleColor.h > needs to become private? I don't see StyleColor.h being included anywhere > outside of WebCore.
StyleColor.h isn't, but RenderTheme.h is, which now includes StyleColor.h. I hit WebKit build errors without this.
Timothy Hatcher
Comment 10
2018-04-06 20:50:43 PDT
Comment on
attachment 337380
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=337380&action=review
>>> Source/WebCore/ChangeLog:4 >>> + >> >> Nit - extra newline here. > > Okay. I'll give that a try.
Not sure why this comment went here.
>> Source/WebCore/PAL/ChangeLog:3 >> + Use the system's link color when system appearance is desired for a WebView. > > Could we write an API test for this? I imagine we could do something like: > > 1. Swizzle out +[NSColor linkColor] > 2. Load an HTML string with a link > 3. Evaluate JavaScript to query the computed style of the link > > There are helpers to make (2) and (3) more convenient if you create a TestWKWebView, and (1) can be accomplished via ClassMethodSwizzler (also see TestWebKitAPI).
Okay. I'll give that a try.
Timothy Hatcher
Comment 11
2018-04-06 23:18:27 PDT
Created
attachment 337417
[details]
Patch
Timothy Hatcher
Comment 12
2018-04-06 23:21:23 PDT
(In reply to Wenson Hsieh from
comment #7
)
> Could we write an API test for this? I imagine we could do something like: > > 1. Swizzle out +[NSColor linkColor] > 2. Load an HTML string with a link > 3. Evaluate JavaScript to query the computed style of the link > > There are helpers to make (2) and (3) more convenient if you create a > TestWKWebView, and (1) can be accomplished via ClassMethodSwizzler (also see > TestWebKitAPI).
I wrote an API test that checks link color. I couldn't use ClassMethodSwizzler, since that needs to swizzle in the web process, not the UI process. I did test with system appearance on and off. I also couldn't test visited links, since we hide visited colors from JavaScript.
Timothy Hatcher
Comment 13
2018-04-06 23:43:09 PDT
Created
attachment 337418
[details]
Patch
Wenson Hsieh
Comment 14
2018-04-07 00:00:02 PDT
Comment on
attachment 337418
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=337418&action=review
> Source/WebCore/ChangeLog:4 > +
Nit - extra new line in these ChangeLog entries.
WebKit Commit Bot
Comment 15
2018-04-07 01:35:05 PDT
Comment on
attachment 337418
[details]
Patch Clearing flags on attachment: 337418 Committed
r230368
: <
https://trac.webkit.org/changeset/230368
>
WebKit Commit Bot
Comment 16
2018-04-07 01:35:07 PDT
All reviewed patches have been landed. Closing bug.
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