L.G.T.M.
LGTM!!
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
What about alert messages and the debugger? They are no different from the modal dialog - they run nested event loops on arbitrary JS stack and make same web calls reentrant. What part of the complexity is going away with the showModalDialog?
Regards
Pavel
showModalDialog allows one WebView to schedule work, whereas with alert/confirm/prompt/print, no WebView may schedule work.
What about debugger? Mutating DOM and evaluating setTimeout from the console while on a breakpoint is a generic use case for us.
The debugger at least doesn't let the page decide to start a nested message loop.
Also, it doesn't require the entire browser to stop doing anything else (note that this is actually broken in chrome - the dialog is currently not modal).
Last but not least, we could do something similar on the main thread to what I recently added for workers: add a separate message queue for debugger tasks, then we don't need a nested message loop anymore.
Best
Jochen
Alright. I just wanted to bring attention to other use cases that require similar complexity. Given they are on radar, this intent looks good.
Jochen, I'll follow up with you on a separate message queue. WebView might be not as simple as worker there.
Regards
Pavel
I'm surprised nobody's really spoken up about the negative effects of this change. I'll try not to make this too rant-y but...
I'm kind of amused at the fact that everyone's quick to say L.G.T.M. without giving any consideration to the implications of a change like this. It seems like this is being removed only because its 'hard to do' and 'nobody uses it'. What real good reason do you have to remove it? Last I checked, its in the HTML5 spec. Maybe I'm crazy and I'm missing something.
What about the people who do use it? Did you guys every think about web application usage? Just to clarify, I'm talking business applications here. Of course you'll only see a small percentage because most people are looking at cat pics or wasting their lives on facebook. I feel like no real research has gone into examining the overall effects of this. Somebody did a web search and said that's good enough. Absolutely ludicrous.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
"We sent out these announcements so that the community can let us know about any potential issues so we can react to them. We need to know about concrete real-world uses in order to make an informed decision."Well, that's us, for instance. Part of our web based application is content creation, using CKEditor on part of the page. Our users are effectively creating HTML pages, and sometimes need more room than is available in the region of the page CK is restricted to. For this reason we have a button that reopens CKEditor in a detached window that can use the whole screen. This has to be modal so changes can't be made in the smaller version at the same time.
We use showModalDialog() for this, because it conveniently pauses execution in the opener until the window closes, at which point it returns (via window.returnValue) the new content and we can just update.
The 'fix' for loosing showModalDialog() would be to display a full-page overlay, right ? This is not as useful as a detached window, because I have to resize the browser (and all its tabs) rather than just the window of interest.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
The showModalDialog method along with alert and prompt are one of the few true blocking calls. Implementing a polyfill is next to IMPOSSIBLE without crashing the browser.Here is an example of why:var returnValue = window.showModalDialog(<someuri>);Now since this is a blocking call window.showModalDialog will not return until the child window (<someurl>) calls a window.close on itself.There is no practical way to simulate a blocking call in javascript to write out a backward compatible javascript polyfill.
Here is a practical example of a use case that is in production on a multi million dollar product.A user is clicking on a feature that requires some setup before it continues to render the page.var featureConfig = window.showModalDialog(<someUrl>); //someUrl might be a wizard walking the user through the complex flow to finally submit the results back to the parent window as the result object.Since the call was blocking the code is scripted to assume a synchronous nature of the method call..
I also have a concern regarding the source of the data in making a swift decision. Most of these method calls tend to happen on pages that require a logged in context. Hence this will not show in a grep search of the top public websites. The amount of work involved in converting a previously synchronous flow (by leveraging the blocking nature of window.showModal) into asynchronous one is not trivial.
This will cause significant issues for some applications and may require more than 3 months of notice to fix.
var featureConfig = window.showModalDialog(<someUrl>); //someUrl might be a wizard walking the user through the complex flow to finally submit the results back to the parent window as the result object.Since the call was blocking the code is scripted to assume a synchronous nature of the method call..To address that use case, you'll probably want to create a full-page element that dims the existing content of the page and prevents the user from interacting with it. You can position your custom dialog on top of that element to let the user interact with the dialog. That's how most web apps handle this use case.
Adam,Don't get me wrong, I am totally in favor of removing this from the browser codebase as it simplifies a lot of things and truly reflects the asynchronous nature of javascript by removing the blocking methods.At the same time, we do also want to point out that despite making progress on the reducing/removing the use of blocking calls, three months is not enough for us. Out entire app (an older version) that has more that half a million active users will be impacted pretty significantly as we will not be able to turnaround in time. We have a fairly large codebase that uses this feature a lot.At this point, is it a given that this will be removed in the next release of chrome or do we have a chance to postpone the removal of this feature by one more release ?
Hi Adam,I'm a colleague of Tapasvi's. I read somewhere at the top of the thread that you were open to information on actual product usage to inform your decision, and I hope that you reconsider the timing for this change.Our product is a mission critical application for small businesses. We have over 1 million active small business users who depend on us on a daily basis. We rely heavily on showModalDialog - we have hundreds of instances of these throughout the code. These dialogs are used in core workflows and implementing large parts of the functionality of the application - removing this API will render the product unusable. 3 months is simply not enough time for us to react to this change.
UseCounters measure both logged in and not logged in content in proportion to how often that content is viewed by users. The fact is that showModalDialog is used extremely rarely.
This will cause significant issues for some applications and may require more than 3 months of notice to fix.
I appreciate that it's going to be some amount of work for you to retrofit your web site to avoid showModalDialog. We understand that's a cost of removing this feature. On balance, however, we feel that the benefits of removing the feature outweigh the costs.
On Mon, Mar 3, 2014 at 7:00 PM, Adam Barth <aba...@google.com> wrote:
UseCounters measure both logged in and not logged in content in proportion to how often that content is viewed by users. The fact is that showModalDialog is used extremely rarely.One note - the assumption behind UseCounters is that the population with UseCounter reporting enabled is roughly equivalent (in terms of frequency of usage of APIs) to the population that has UseCounter reporting disabled. If there's an API that is primarily used by enterprises (which have a much higher percentage of clients with usage reporting disabled), then that would skew our numbers.So, we should be cautious about treating statistical projections based on UseCounters as "facts" - they are projections based on the best data we have available, but data which is known to be flawed.I would echo Jochen's concern that SAP applications make use of this API, and this use by enterprise apps is likely to be under-reported by UseCounters. I understand the motivation to remove this API (and it's a bit of a fait accompli at this point), but ideally we'd have some time to do outreach with our enterprise customers/ISVs, and I fear that 8-12 weeks will be insufficient.This will cause significant issues for some applications and may require more than 3 months of notice to fix.
I appreciate that it's going to be some amount of work for you to retrofit your web site to avoid showModalDialog. We understand that's a cost of removing this feature. On balance, however, we feel that the benefits of removing the feature outweigh the costs.I wouldn't say that the cost is outweighed by the benefit, just that ideally we would give people more time to make this transition, especially since the first time many of them will hear about this is when this change hits the Chrome beta channel.
Adam/Eric,We've done some more detailed assessment and tried a couple of workaround options. As you know, the challenge is in replicating the blocking nature of the showModalDialog call while still solving for the use cases. The short answer is that we will need through October 31st to deal with this change. Please read on for the rationale.Within our code, we pause execution in the parent, wait for the return value from this call, and use that return value to continue execution in the caller. Sometimes, the hierarchy takes us multiple levels deep from dialog to dialog. There are arguments being passed back and forth across the dialogs, and as I mentioned, we have very core business/domain workflows implemented in this way (so the dialogs are pretty heavyweight). While we'd like to move away from using these dialogs, this is a very large undertaking for us. It requires us to touch every instance of the call (dialog + caller) to enable the same behavior, making changes up and down that entire call stack. There are 600+ instances that we need to track down and modify without regression.Given this complexity and scope, we will need all hands on deck to implement these workarounds, and we're estimating that it'll take 8 months for us to do it. Obviously, this is pretty disruptive to the business and it deprioritizes other work we have in flight in order to focus on this effort.Please let me know your thoughts.
To be fair, this feature has been deprecated for three months already. The deprecation period is the time to move off an API.
+1
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?
I say this, because I'm on the Chrome Enterprise team, and we weren't aware that this API was going away until yesterday.
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?
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.
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.
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".
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:That data only goes back a month, but even in that time, the usage has fallen significantly.
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.
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: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?
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
Yes, it can be made simpler but main problem remains that we lost code execution pause feature.
Assume we have many confirmation dialog, we have to split code to many pieces that results a very ugly code.
21 Mart 2014 Cuma 17:27:55 UTC+2 tarihindehistucK yazdı:
Use counter data from the stable channel shows that window.showModalDialog() is used on less than 0.006% of page visits. This feature has an incredibly high cost in terms of code complexity since it requires us to run an event loop on top of an arbitrary javascript stack. It also complicates the web platform by making task dispatch reentrant and hard to reason about. To this day, it's unclear how microtask delivery should work with this API.We marked this API as deprecated 3 months ago:and given the usage numbers I believe we should remove this from Blink now and see how web compatible this ends up being. Even if we suffer a bit of pain, I think it's worthwhile to remove this functionality. In particular I do not think we need to tie this removal to any other features like <dialog>.- James
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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?
I say this, because I'm on the Chrome Enterprise team, and we weren't aware that this API was going away until yesterday. 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? 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.Adam
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.☆PhistucKOn 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.
On Thu Mar 06 2014 at 5:02:16 PM, <yog...@gmail.com> wrote:Adam/Eric,We've done some more detailed assessment and tried a couple of workaround options. As you know, the challenge is in replicating the blocking nature of the showModalDialog call while still solving for the use cases. The short answer is that we will need through October 31st to deal with this change. Please read on for the rationale.Within our code, we pause execution in the parent, wait for the return value from this call, and use that return value to continue execution in the caller. Sometimes, the hierarchy takes us multiple levels deep from dialog to dialog. There are arguments being passed back and forth across the dialogs, and as I mentioned, we have very core business/domain workflows implemented in this way (so the dialogs are pretty heavyweight). While we'd like to move away from using these dialogs, this is a very large undertaking for us. It requires us to touch every instance of the call (dialog + caller) to enable the same behavior, making changes up and down that entire call stack. There are 600+ instances that we need to track down and modify without regression.Given this complexity and scope, we will need all hands on deck to implement these workarounds, and we're estimating that it'll take 8 months for us to do it. Obviously, this is pretty disruptive to the business and it deprioritizes other work we have in flight in order to focus on this effort.Please let me know your thoughts.Yogesh,I sympathize with your situation. No one wants to distract their development team for re-writing large portions of their app because an API they depend upon has been removed.Unfortunately, in the period of time this thread has been going on, we've received a report of yet another security vulnerability with showModalDialog (http://crbug.com/350535 for those of you who can access security bugs or those of you reading this email in the future). On the one hand, that's not particularly surprising because we've seen a long series of vulnerabilities in showModalDialog over the years, but, on the other hand, it makes the costs of keeping showModalDialog very concrete.What makes removing features like showModalDialog difficult is that the costs are large but borne by relatively few people but the benefits are small but enjoyed by a relatively large number of people. It can be difficult to judge whether the costs or benefits have more weigh. Ultimately, that's a judgement call, and our judgement is that the benefits outweigh the costs.I understand that you're on the cost side of this equation, but I would ask you to understand that there are people on the benefit side of this equation too.Adam
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Anyway I think a web developer Roadmap when Chrome depreciates a features and when it is intended to beeing removed is urgently need, currently I find it very hard to get information on the chromium site as the informatins are really widespread and have to searched for here and there. Or am i wrong?
On 28 May 2014 07:11, <musafi...@gmail.com> wrote:
> Is there any alternative solution in chrome which give us same functionality as showModalDialog() blocks the parent thread. I have tried javascript promise to open modal dialog with jquery but that does not block the parent thread and if we want to implement that we have to undergo a huge change.
No. The whole reason we want to remove showModalDialog is *because* it blocks the parent window, which is difficult to implement in a sane way. Modern web APIs are asynchronous, and you would need to restructure your application to be asynchronous too.