Bug 28057 – deprecatedCopyInheritableProperties must be replaced by two different functions

• Component: HTML Editing
• Status: RESOLVED FIXED

[Ryosuke Niwa]

As a follow up to https://bugs.webkit.org/show_bug.cgi?id=27325, deprecatedCopyInheritableProperties must be replaced by two separate functions:

1. Preparing style to apply - Delete CSS properties that are already present at the specified position from a mutable style.
2. Typing styles - Retrieve mutable style merged with the typing style

[Ryosuke Niwa]

Created attachment 34235 [details]
adds new functions to ApplyStyleCommand.* and removes deprecatedCopyInheritableProperties

[Eric Seidel (no email)]

Comment on attachment 34235 [details]
adds new functions to ApplyStyleCommand.* and removes deprecatedCopyInheritableProperties

I don't believe you that this doens't change behavior.

A bunch of the editingStyleAtPosition calls now use IncludeTypingStyle which didn't before.

[Ryosuke Niwa]

This patch follows the rules below:

1. styleAtPosition merges the computed style at the position and the typing style. So every instance of styleAtPosition MUST be replaced by editingStyleAtPosition(selection.start(), IncludeTypingStyle);

2. computedStyle(<node>)->deprecatedCopyInheritableProperties()->diff(<style>) or any two-line codes that does a similar thing MUST be replaced by prepareEditingStyleToApplyAt(<style>, Position(<node>, 0)).  Note that prepareEditingStyleToApplyAt uses IgnoreTypingStyle implicitly.

3. All other instances of computedStyle(<node>)->deprecatedCopyInheritableProperties must be replaced by editingStyleAtPosition(positionBeforeTabSpan(Position(<node>,0));

[Ryosuke Niwa]

Landed in http://trac.webkit.org/changeset/46914.

[Eric Seidel (no email)]

This is believed to have caused http://code.google.com/p/chromium/issues/detail?id=21203.  I'm not sure if that has a WebKit bug yet, it certainly needs one.

[Ryosuke Niwa]

(In reply to comment #5)
> This is believed to have caused
> http://code.google.com/p/chromium/issues/detail?id=21203.  I'm not sure if that
> has a WebKit bug yet, it certainly needs one.

https://bugs.webkit.org/show_bug.cgi?id=28710 is the corresponding WebKit bug.