Branch: refs/heads/webkitglib/2.38
Home: https://github.com/WebKit/WebKit
Commit: caf4fba3501c1722a2845185d7dbec54c90465ea
https://github.com/WebKit/WebKit/commit/caf4fba3501c1722a2845185d7dbec54c90465ea
Author: Antti Koivisto <[email protected]>
Date: 2023-04-06 (Thu, 06 Apr 2023)
Changed paths:
M Source/WebCore/style/AttributeChangeInvalidation.cpp
Log Message:
-----------
Cherry-pick 261076@main (2c5baee03fa2).
https://bugs.webkit.org/show_bug.cgi?id=253067
nullptr crash in WebCore::SelectorChecker::attributeSelectorMatches
https://bugs.webkit.org/show_bug.cgi?id=253067
rdar://105628059
Reviewed by Geoffrey Garen and Alan Baradlay.
Speculative fix.
* Source/WebCore/style/AttributeChangeInvalidation.cpp:
(WebCore::Style::AttributeChangeInvalidation::invalidateStyle):
Check that we actually have an attribute selector.
Canonical link: https://commits.webkit.org/261076@main
Commit: cd78640792484c6ad9fc84330ec05cb5a7c5c1d6
https://github.com/WebKit/WebKit/commit/cd78640792484c6ad9fc84330ec05cb5a7c5c1d6
Author: Razvan Caliman <[email protected]>
Date: 2023-04-06 (Thu, 06 Apr 2023)
Changed paths:
M Source/WebInspectorUI/UserInterface/Models/DOMNodeStyles.js
M
Source/WebInspectorUI/UserInterface/Views/SpreadsheetRulesStyleDetailsPanel.js
Log Message:
-----------
Cherry-pick 261883@main (96c03ed0c66b).
https://bugs.webkit.org/show_bug.cgi?id=253956
Web Inspector: Styles Panel: Adding a new CSS rule doesn't work on first
attempt
https://bugs.webkit.org/show_bug.cgi?id=253956
Reviewed by Patrick Angle.
To add a new CSS rule, an inspector stylesheet is first created.
This operation triggers a `DOMNodeStyles.refresh()`.
The operation to add the new rule to this stylesheet also triggers a
refresh. But if the promise for the first refresh is still pending,
the second call is ignored. This means that the Styles panel ends up
not showing any matching styles from the initially empty stylehseet.
A subsequent call to add a new rule bypasses the need to create a new
stylesheet. The `DOMNodeStyles.refresh()` it trigges brings the Styles
panel in sync with the latest contents of the inspector-generated
stylehseet.
That's why two rules show up on the first successful attempt.
The logic to mark the newly created rule's selector as editable is too
lenient:
it marks all CSS rules with a selector identical to the one of the newly
created rule.
This patch makes a stricter check by identifying the newly created rule by
its `CSSStyle.styleId`.
* Source/WebInspectorUI/UserInterface/Models/DOMNodeStyles.js:
(WI.DOMNodeStyles.prototype.addRule.completed):
(WI.DOMNodeStyles.prototype.addRule.addedRule):
*
Source/WebInspectorUI/UserInterface/Views/SpreadsheetRulesStyleDetailsPanel.js:
(WI.SpreadsheetRulesStyleDetailsPanel):
(WI.SpreadsheetRulesStyleDetailsPanel.prototype.spreadsheetCSSStyleDeclarationSectionAddNewRule):
(WI.SpreadsheetRulesStyleDetailsPanel.prototype.layout):
(WI.SpreadsheetRulesStyleDetailsPanel.prototype._addNewRule):
(WI.SpreadsheetRulesStyleDetailsPanel.prototype._addedNewRuleCallback):
Canonical link: https://commits.webkit.org/261883@main
Commit: d77f824d9e1f56ea4bd164cf51efcee5fa2684a9
https://github.com/WebKit/WebKit/commit/d77f824d9e1f56ea4bd164cf51efcee5fa2684a9
Author: Chris Dumez <[email protected]>
Date: 2023-04-06 (Thu, 06 Apr 2023)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter-non-broken.html
A
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter-sameish-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter-sameish.html
M
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter.html
M
LayoutTests/imported/w3c/web-platform-tests/url/url-setters-stripping.any-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/url/url-setters-stripping.any.worker-expected.txt
M Source/WTF/wtf/URLParser.cpp
Log Message:
-----------
Cherry-pick 261017@main (0c6de669a59b).
https://bugs.webkit.org/show_bug.cgi?id=251087
Strip tab and newline from Location/URL/<a>/<area>'s protocol setter
https://bugs.webkit.org/show_bug.cgi?id=251087
rdar://104599983
Reviewed by Alex Christensen.
Our URL parser was already skipping newlines and tabs in the scheme while
parsing. However, URL::setProtocol() would call
URLParser::maybeCanonicalizeScheme()
before parsing and this function would fail if the protocol contains any
newlines or tabs.
*
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter-non-broken.html:
*
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter-sameish-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter-sameish.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/html/browsers/history/the-location-interface/location-protocol-setter.html:
Resync tests after https://github.com/web-platform-tests/wpt/pull/38032.
*
LayoutTests/imported/w3c/web-platform-tests/url/url-setters-stripping.any-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/url/url-setters-stripping.any.worker-expected.txt:
Rebaseline tests that are now passing.
* Source/WTF/wtf/URLParser.cpp:
(WTF::URLParser::maybeCanonicalizeScheme):
Update URLParser::maybeCanonicalizeScheme() to allow for newlines and tabs
in
the scheme since it is allowed by the specification and our URL parser
actually
handles them fine.
Canonical link: https://commits.webkit.org/261017@main
Compare: https://github.com/WebKit/WebKit/compare/ed0f829ea48e...d77f824d9e1f
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes