Deprecation dissemination process WAS Re: [blink-dev] Re: Intent to Remove: window.showModalDialog()

[Max Heinritz]

[ branching thread from showModalDialog specifics to focus on deprecation more generally ]

On Wed, Mar 12, 2014 at 10:15 AM, Eric Seidel <ese...@chromium.org> wrote:

I've been taking some notes on this thread, which I've now published:

https://docs.google.com/document/d/1WxCkKj28fnvkD0nSZTeu-prjQyg-Hg4acJwEEooZIek/pub

commi...@chromium.org have edit access:

https://docs.google.com/a/chromium.org/document/d/1WxCkKj28fnvkD0nSZTeu-prjQyg-Hg4acJwEEooZIek/edit

AFAICT we failed to send an Intent To Deprecate about this removal, deviating from our published guidelines.

Indeed.  We should have mentioned this deprecation in the Chrome 32 Beta post on the Chromium Blog.

I've been responsible for aggregating web platform API updates (new features, deprecations, removals) and curating them for broader consumption in the Chromium posts.  Sorry for missing this one.  I think our current approach is fine, but we just messed up in this specific case.

To figure what changed in each release, I typically:

1. Review chromestatus.com features targeted at the release.
   
2. Scrub the OWP launch tracking bugs.
3. Look at the intent spreadsheet for anything shipped, removed, or deprecated but not found in #1 or #2.
4. Discuss findings from 1-3 with Google's Blink leadership in person before each branch point.

This change managed to slip through all of these steps.  To remedy the situation, I think two things need to change:

• Always send relevant Intents and enforce this in review.  We deviated from the guidelines here.  As I see it, this falls largely on the API Owners for enforcement.
• I personally need to do a better job curating Chromium Blog updates about deprecations and removals.  The shortcut in the 34 Beta post of pointing to the Blink Intents spreadsheet clearly isn't good enough.

What do you think?

On Wed, Mar 12, 2014 at 9:27 AM, Jochen Eisinger <joc...@chromium.org> wrote:

On Wed, Mar 12, 2014 at 5:24 PM, Drew Wilson <atwi...@chromium.org> wrote:

To follow up after my offline discussion with jochen - a significant portion of the world's web pages are rendered by Blink, and that means that the security benefits from removing fragile APIs like this are commensurately large. However, I'd say that the size of our user base also means that we have an obligation to do an *outstanding* job of publicizing changes like this, because we're large enough that we're effectively changing the web platform when we do this.

Currently, it seems like our public notification of this change was:

1) A warning printed to the JS console for the last couple of months.

2) This email sent to blink-dev announcing our intent to remove on Feb 21 (roughly 3 months before this would hit the stable channel)

3) Line 57 from the "Blink Intents" spreadsheet, linked from a Chrome 34 beta release blog post:

My concern is that not enough web developers will see any of these notifications. So, to make a concrete suggestion, I'd like to propose that the blink/chrome team publish a blog post at the start of every quarter, stating which APIs we intend to remove the following quarter. This has the side effect of slowing down the velocity of deprecations (if I put up a blog post on Jan 1 announcing our intent to remove API XXXX in Q2, then it likely doesn't the stable channel until midway through Q2, giving developers effectively 5 months to take action).

Jochen expressed his opinion that at this point we've already removed most of the APIs we're planning to

Just to clarify: APIs of the kind of showModalDialog() not in general.

 

deprecate, and that the current process/level of communication has been working OK so far, so this is basically not worth pursuing. And if that's the case, then OK. I just want to make sure that the blink team is aware of the fact that folks outside the team don't have the level of visibility into their plans that the blink team has been assuming.

-atw

On Wed, Mar 12, 2014 at 12:26 PM, PhistucK <phis...@gmail.com> wrote:

By the way, this is not a very good list, as it does not say to which Chrome version the date of the intent (or actual addition, deprecation or removal commit) corresponds. Also, the audience must be familiar with your terms and the rules for actually acting on an intent (red means it is not approved, green means it is and might have happened).

This should really not be linked from a release notes blog post as it is too internal for the wider audience to comprehend.

☆PhistucK

On Wed, Mar 12, 2014 at 12:56 PM, Jochen Eisinger <joc...@chromium.org> wrote:

On Wed, Mar 12, 2014 at 10:27 AM, Drew Wilson <atwi...@chromium.org> wrote:

On Tue, Mar 11, 2014 at 4:14 PM, Adam Barth <aba...@google.com> wrote:

On Tue Mar 11 2014 at 2:35:00 AM, Drew Wilson <atwi...@chromium.org> wrote:

On Mon, Mar 10, 2014 at 4:50 PM, Adam Barth <aba...@google.com> wrote:

To be fair, this feature has been deprecated for three months already.  The deprecation period is the time to move off an API.

Agreed, 3 months is a reasonable timeframe. What does it mean for an API to be deprecated - do we do any developer outreach letting people know that the API is going away, or is the deprecation warning printed to the JS console the only notification we provide?

Deprecation messages are printed to the console and announced on this mailing list.  Some deprecations are announced on the Chromium blog, but I don't see that this one was.  We could certainly do a better job publicizing when we deprecate a feature.

 

I say this, because I'm on the Chrome Enterprise team, and we weren't aware that this API was going away until yesterday.

 

In the near term, the easiest way to learn about deprecations is to search this mailing list for messages with the subject "intent to deprecate" or "intent to remove".

Jochen pointed this out also, and I've now set up the appropriate filters to make sure I'm able to track upcoming changes like this :)

 

Undoubtedly that's our own fault for not making sure we keep ourselves informed about developments in Blink, but I suspect that many other developers were unaware that this was coming. Did we see use of this API decrease over the last 3 months?

Yes, the usage as been declining:

http://www.chromestatus.com/metrics/feature/timeline/popularity/195

That data only goes back a month, but even in that time, the usage has fallen significantly.

Thanks - that's a pretty dramatic decline, so it does seem to show that our deprecation process is working.

 

If so, then that would be a signal that our deprecation process is working as intended, and at some point we just need to pull the plug. My concern is that if we didn't see the use decline, that means that developers were generally unaware of the deprecation.

I suspect that people don't take deprecation seriously because historically we haven't actually followed through and removed features that we've deprecated.  For example, there's another thread on this mailing list currently about a deprecated feature that's used by 24% of pages.  It's very unlikely we'd be able to remove a feature that's used by 24% of pages.  Hopefully we'll raise the signal-to-noise ratio of these messages.

One of our goals for 2014 is to find ways to deprecate and remove large platform features with minimal breakage [1].  We're still learning how to do that effectively.  I really appreciate your feedback about how we can do better in the future.  Hopefully over time we'll iron out the rough spots in this process.

I think the overall goals of the blink and chromium teams (removing functionality like showModalDialog, NPAPI) are sound - we can't let ourselves be permanently handcuffed to insecure or poorly designed features. But we should also be cognizant of the fact that more and more enterprises are adopting Chrome precisely because of our focus on stability and security, and these enterprise customers expect a fairly rigorous deprecation process.

I would point at Chrome's removal of NPAPI support as a good example of how we might remove web platform features - there was ample notification, including end-user-visible notification, and a well-publicized deadline that gave partners ample time to migrate to new solutions. Now, granted, NPAPI has several orders of magnitude more adoption than showModalDialog() so it's not likely that we would have such a heavy-weight process for removing that API. But I would think that a public blog post at the time of deprecation, stating that we're deprecating the API and plan to remove it within 120 days would have been appropriate and fairly lightweight. Is there a way to make this part of the deprecation/removal process?

The chromium blog post contains a link to a list of all added, deprecated, and removed features: http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html

best

-jochen

 

 

Adam

[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Z5OzwYh3Wfk/IWooaY5FZowJ

 

On Friday, February 28, 2014 4:56:58 AM UTC-8, PhistucK wrote:

I think a polyfill for (an even less buggy version of) showModalDialog would be pretty trivial to implement (like Jochen mentions, window.open, window.onmessage and opener.postMessage). While the JavaScript execution would not be halted (which does not change the current state in Chrome), you can make use of this CSS -

*

{

 pointer-events: none !important;

}

To make sure no (mouse or touch) events are triggered (as part of the polyfil).

Then just include the polyfill in both of the ends of that interaction and you should be done.

The JavaScript execution bug will probably never be fixed anyway, so there is no reason to ever count on it.

☆PhistucK

On Fri, Feb 28, 2014 at 2:28 PM, <tom.ch...@gmail.com> wrote:

"Of course you lose the modality aspect, but as you note below, that never really worked in chrome..."

Yup. Which is why we use it, and we've always considered it a bug in Chrome that would get fixed, rather than Chrome deciding it could pick and choose what parts of HTML5 to support.

Tom

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

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

[Konrad Piascik]

Hi,

If you want to spead the information about deprecation to the web community it may be useful to get their attention in places they visit. http://caniuse.com/ is a site that is referenced and source by many developers and other websites for what features are available in which browser. Helping the developer who keeps this site relevant and updated with deprecations may be useful than a console message.

Just my $0.02,
Konrad
________________________________________
From: m...@google.com [m...@google.com] on behalf of Max Heinritz [m...@chromium.org]
Sent: Wednesday, March 12, 2014 2:19 PM
To: Eric Seidel
Cc: Jochen Eisinger; Drew Wilson; PhistucK; Adam Barth; sas...@chromium.org; Tapasvi Moturu; blink-dev; Tom Chiverton
Subject: Deprecation dissemination process WAS Re: [blink-dev] Re: Intent to Remove: window.showModalDialog()

[ branching thread from showModalDialog specifics<https://docs.google.com/a/google.com/document/d/1WxCkKj28fnvkD0nSZTeu-prjQyg-Hg4acJwEEooZIek/pub> to focus on deprecation more generally ]

On Wed, Mar 12, 2014 at 10:15 AM, Eric Seidel <ese...@chromium.org<mailto:ese...@chromium.org>> wrote:
I've been taking some notes on this thread, which I've now published:
https://docs.google.com/document/d/1WxCkKj28fnvkD0nSZTeu-prjQyg-Hg4acJwEEooZIek/pub

commi...@chromium.org<mailto:commi...@chromium.org> have edit access:

https://docs.google.com/a/chromium.org/document/d/1WxCkKj28fnvkD0nSZTeu-prjQyg-Hg4acJwEEooZIek/edit

AFAICT we failed to send an Intent To Deprecate about this removal, deviating from our published guidelines.

Indeed. We should have mentioned this deprecation in the Chrome 32 Beta post<http://blog.chromium.org/2013/11/chrome-32-beta-animated-webp-images-and.html> on the Chromium Blog.

I've been responsible for aggregating web platform API updates (new features, deprecations, removals) and curating them for broader consumption in the Chromium posts. Sorry for missing this one. I think our current approach is fine, but we just messed up in this specific case.

To figure what changed in each release, I typically:

1. Review chromestatus.com<http://chromestatus.com> features targeted at the release.
2. Scrub the OWP launch tracking bugs<https://code.google.com/p/chromium/issues/list?can=1&q=Type%3DLaunch-OWP+-Status%3DFixed&colspec=ID+Pri+Mstone+ReleaseBlock+OS+Area+Feature+Status+Owner+Summary&x=mstone&y=owner&cells=tiles>.
3. Look at the intent spreadsheet<https://docs.google.com/spreadsheet/ccc?key=0AjGgk26K1Cc-dHJKNGtlLVlmSGRIYVR3LVRGYnVCRVE&usp=drive_web#gid=0> for anything shipped, removed, or deprecated but not found in #1 or #2.
4. Discuss findings from 1-3 with Google's Blink leadership in person before each branch point.

This change managed to slip through all of these steps. To remedy the situation, I think two things need to change:

* Always send relevant Intents and enforce this in review. We deviated from the guidelines here. As I see it, this falls largely on the API Owners for enforcement.
* I personally need to do a better job curating Chromium Blog updates about deprecations and removals. The shortcut in the 34 Beta post<http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html> of pointing to the Blink Intents spreadsheet clearly isn't good enough.

What do you think?

On Wed, Mar 12, 2014 at 9:27 AM, Jochen Eisinger <joc...@chromium.org<mailto:joc...@chromium.org>> wrote:

On Wed, Mar 12, 2014 at 5:24 PM, Drew Wilson <atwi...@chromium.org<mailto:atwi...@chromium.org>> wrote:
To follow up after my offline discussion with jochen - a significant portion of the world's web pages are rendered by Blink, and that means that the security benefits from removing fragile APIs like this are commensurately large. However, I'd say that the size of our user base also means that we have an obligation to do an *outstanding* job of publicizing changes like this, because we're large enough that we're effectively changing the web platform when we do this.

Currently, it seems like our public notification of this change was:

1) A warning printed to the JS console for the last couple of months.
2) This email sent to blink-dev announcing our intent to remove on Feb 21 (roughly 3 months before this would hit the stable channel)
3) Line 57 from the "Blink Intents" spreadsheet, linked from a Chrome 34 beta release blog post:

[Inline image 1]

My concern is that not enough web developers will see any of these notifications. So, to make a concrete suggestion, I'd like to propose that the blink/chrome team publish a blog post at the start of every quarter, stating which APIs we intend to remove the following quarter. This has the side effect of slowing down the velocity of deprecations (if I put up a blog post on Jan 1 announcing our intent to remove API XXXX in Q2, then it likely doesn't the stable channel until midway through Q2, giving developers effectively 5 months to take action).

Jochen expressed his opinion that at this point we've already removed most of the APIs we're planning to

Just to clarify: APIs of the kind of showModalDialog() not in general.

deprecate, and that the current process/level of communication has been working OK so far, so this is basically not worth pursuing. And if that's the case, then OK. I just want to make sure that the blink team is aware of the fact that folks outside the team don't have the level of visibility into their plans that the blink team has been assuming.

-atw

On Wed, Mar 12, 2014 at 12:26 PM, PhistucK <phis...@gmail.com<mailto:phis...@gmail.com>> wrote:
By the way, this is not a very good list, as it does not say to which Chrome version the date of the intent (or actual addition, deprecation or removal commit) corresponds. Also, the audience must be familiar with your terms and the rules for actually acting on an intent (red means it is not approved, green means it is and might have happened).

This should really not be linked from a release notes blog post as it is too internal for the wider audience to comprehend.


☆PhistucK

On Wed, Mar 12, 2014 at 12:56 PM, Jochen Eisinger <joc...@chromium.org<mailto:joc...@chromium.org>> wrote:



On Wed, Mar 12, 2014 at 10:27 AM, Drew Wilson <atwi...@chromium.org<mailto:atwi...@chromium.org>> wrote:



On Tue, Mar 11, 2014 at 4:14 PM, Adam Barth <aba...@google.com<mailto:aba...@google.com>> wrote:
On Tue Mar 11 2014 at 2:35:00 AM, Drew Wilson <atwi...@chromium.org<mailto:atwi...@chromium.org>> wrote:

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






To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org<mailto:blink-dev+...@chromium.org>.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

[PhistucK]

I agree. caniuse.com, MDN and docs.webplatform.org come to mind.

☆PhistucK

[Max Heinritz]

Thanks for chiming in.

Directly updating caniuse.com is an interesting idea.  Glancing around, its current data set doesn't seem granular enough to include features we've been deprecating (e.g. none of Node.isSupported, window.showModalDialog, or XSLT appear there).  Of course, that could change, but it makes me question how appropriate that channel is.

I think the best thing for Chromium to do is offer an easy-to-digest yet complete source of truth about what is changing in Blink's API surface each release (and, for deprecation, what's expected to change soon).  This is the intention of the Chromium Blog posts accompanying every Chrome Beta release.  Many of these posts mention deprecations, but we admittedly haven't done as thorough of a job with deprecation as we could have.  That will change going forward.  In the case of major deprecations, e.g. NPAPI, we sometimes use even louder signals (e.g. a dedicated Chromium post).

IMO, we can and should count on the broader web community to spread the message e.g. on social networks, MDN, WPD, etc.  Chromium should focus a) on getting the source of truth (i.e. the Chromium posts) to be accurate, since clearly we're not quite there yet, and b) making the web performant on mobile.

Max 

[Max Heinritz]

FYI Opera wrote an amazing post explaining the showModalDialog deprecation: http://dev.opera.com/articles/view/showmodaldialog/

We're planning to link to it from the Chromium Blog post for Chrome 35 Beta.

Max

[Arunprasad Rajkumar]

Is it possible to add a wrench menu item (like Show Deprecated Lists) or chrome://deprecated ?, so that anyone could easily get to know the list of deprecated items without visiting multiple blogs.

<BR/>

<Arun/>

[PhistucK]

That sounds good, as the information is already in the code. But a single web page that aggregates all of the deprecated features is probably a better choice, as long as it is maintains full synchronization with the code.

☆PhistucK

[Arunprasad Rajkumar]

I created a bug[1] and also planning to submit a CL. Any suggestions?

[1] https://code.google.com/p/chromium/issues/detail?id=359012

<BR/>

<Arun/>

[Eric Seidel]

I think that the web is a better place for this information. Making
last-minute changes to the binary (to fix about:deprecations being out
of sync for instance) is hard, and making historical changes is
impossible, where as chromestatus.com can always be updated:
https://github.com/GoogleChrome/chromium-dashboard

Mozilla uses a similar system:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features
https://developer.mozilla.org/en-US/docs/Web/API/Attr#Deprecated_properties_and_methods

I think having a website to hold this information is going to be more
maintainable than burning it into the Chrome binary.

On Wed, Apr 2, 2014 at 3:01 AM, Arunprasad Rajkumar

[Arunprasad Rajkumar]

Hi Eric,

Thanks for your comments.

We are already showing warning message in Inspector console if the deprecated feature is encountered in the running web page. I'm just trying to aggregate all those messages in a separate page (may be chrome://deprecated) as explained in https://code.google.com/p/chromium/issues/detail?id=359012. 

It is not going to be hardcoded by release engineer, but just a pretty HTML page to show the aggregated details from UseCounter::deprecationMessage().

vector<string> GetDeprecatedFeatures() {
  vector<string> messages;
  foreach (feature in Feature) {
    messages.append(UseCounter::deprecationMessage(feature));
  }
  return messages;
}

<BR/>

<Arun/>