Intent to Implement and Ship: Remove designMode inheritance from ancestors

[Daniel Cheng]

Contact emails dch...@chromium.org Spec https://html.spec.whatwg.org/multipage/interaction.html#making-entire-documents-editable:-the-designmode-idl-attribute Summary Change the initial value of document.designMode from "inherit" to "off" and remove support for "inherit". Motivation This brings Blink behavior in line with IE, Firefox, and the spec. As a bonus, it removes some implementation burden for out-of-process iframes. Compatibility Risk Firefox: No public signals Internet Explorer: No public signals Safari: No public signals Web developers: No signals

The proposed changes would make Blink behavior match Firefox and the spec exactly.

Although IE's default value for document.designMode is "inherit", the implemented behavior seems to treat "inherit" similarly to "off". A simple test case is to create a top frame with designMode = "on" and a child frame with designMode = "inherit". I was unable to edit the contents of the child frame in this test case. Describe the degree of compatibility risk you believe this change poses Very low. Ongoing technical constraints None. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no.

Yes. OWP launch tracking bug https://crbug.com/469978 Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5748821980086272 Requesting approval to ship?

Yes.

[Chris Harrelson]

It's hard for me to quantify the risk here. Is there a use counter of document.designMode?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Daniel Cheng]

There is not.

To clarify: I'm not removing document.designMode, just the inheritance aspect of it. I don't see the risk as particularly high given that IE (effectively) and FF both already behave this way.

[Philip Jägenstedt]

To clarify, as implemented in Blink, the document.designMode IDL attribute always returns either "on" or "off". When setting designMode, anything other than "on" or "off" maps to the internal inherit value.

In IE11 the IDL attribute is indeed "inherit" by default, but the documentation lists "inherit" as an alias of "off":

https://msdn.microsoft.com/en-us/library/ie/ms533720%28v=vs.85%29.aspx

So, the main risk is code that sets designMode="on" on a document and depends on the iframes it contains becoming editable. However, since inherit is the default, and this gives a different behavior than in Firefox and IE, one would need to manually inspect the code to understand which behavior was considered correct.

I don't think I've ever encountered nested editable documents, it seems a bit far-fetched. LGTM to match spec without use counters, but if anyone can recall a real-world case of nested editable documents, please speak up.

Philip

[Chris Harrelson]

LGTM subject to adding a UseCounter also, so that we can track going forward.

[Jochen Eisinger]

What would the UseCounter count?

anyway, lgtm3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

Use of document.designMode?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Elliott Sprehn]

We could count how often frames are loaded where they inherit a value of "on". Given that no other browser seems to support this it seems safe to remove it and see what happens on Canary and Dev.

I'm somewhat surprised that OOPI would have any interaction with this though, does designMode propagate across cross origin frames?

On Tue, Mar 24, 2015 at 9:09 AM, Jochen Eisinger <joc...@chromium.org> wrote:

[Daniel Cheng]

Yes, designMode currently propagates across origins.

Daniel