Expose the value of `<meta name="theme-color" content="...">` as SPI

• Component: WebKit API
• Status: RESOLVED FIXED

[Devin Rousso]

.

[Radar WebKit Bug Importer]

<rdar://problem/73586711>

[Devin Rousso]

Created attachment 418330 [details]
Patch

[Tim Horton]

Comment on attachment 418330 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=418330&action=review

> Source/WebCore/html/HTMLMetaElement.cpp:70
> +        process();

This seems... surprising? Did we really not support dynamic change of name before? Should we bother now?

> Source/WebKit/UIProcess/WebPageProxy.h:649
> +    // Set by the WebProcess when parsing `<meta name="theme-color" content="...">`.

Maybe "corresponds to the web content's `<meta name="theme-color" ...`"?

[Devin Rousso]

Comment on attachment 418330 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=418330&action=review

>> Source/WebCore/html/HTMLMetaElement.cpp:70
>> +        process();
> 
> This seems... surprising? Did we really not support dynamic change of name before? Should we bother now?

AFAIK we did not.  I was surprised as well.  According to the spec we should <https://html.spec.whatwg.org/multipage/semantics.html#meta-theme-color>
> If any meta elements are inserted into the document or removed from the document, or existing meta elements have their name or content attributes changed, user agents must re-run the above algorithm and apply the result to any affected UI.

[Devin Rousso]

Also, something I just realized, I should double-check and make sure that the `_themeColor` is `nil`-d out if the page navigates and the new page doesn't have a `<meta name="theme-color" content="...">` (or at least that `_themeColor` stays `nil` until that node is processed).

[Devin Rousso]

Created attachment 418457 [details]
Patch

[Tim Horton]

Comment on attachment 418457 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=418457&action=review

> Source/WebKit/WebProcess/WebPage/WebPage.cpp:3911
> +    layerTransaction.setThemeColor(corePage()->themeColor());

Should this reset m_pendingThemeColorChange? I guess it doesn't matter, it's just a bit funny that it gets stuck if UI-side compositing is on.

[Devin Rousso]

Created attachment 418460 [details]
Patch

[EWS]

Committed r271920: <https://trac.webkit.org/changeset/271920>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 418460 [details].