- Eliminating alert() altogether is just ridiculous. It would breaks tons of existing webs. Is that even standard compliant??

We are not eliminating alert().

- What about confirm()? You certainly cannot get rid of that. Being able to ask confirmation to the user is a vital functionality, and eliminating it would break even more existing code,  and pose security risks, so the issue still persists for confirm() dialogs

We are not eliminating confirm().

- the issue also affect leave/reload-page confirmation dialogs. Are you planning to remove those as well?? 

We are not eliminating onbeforeunload dialogs.

- [...] You don't get rid of it by getting rid of dialogs altogether.

We are not eliminating dialogs.

Cool. So
1- what's the autodismissing thing mentioned in comment 106 of  issue 456 ?
2- how does it address the problem of dialogs being modal to the entire ui rather than the tab they belong to?
3- why do you keep the issue restricted to comments forcing us to discuss this in a duplicate issue?

1- what's the autodismissing thing mentioned in comment 106 of  issue 456 ?

See my work in  bug 629964 .

2- how does it address the problem of dialogs being modal to the entire ui rather than the tab they belong to?

Dialogs will be attached to a tab, and when you switch away from the tab it will dismiss the dialog. That is the "auto-dismissing" bit. This also will allow you to just close a tab while it has a dialog up.

3- why do you keep the issue restricted to comments forcing us to discuss this in a duplicate issue?

Here's the thing: the bugtracker is a tool for Chromium developers to get their work done, a place for technical discussions. Hot bugs like that one attract hundreds of people who post comments like, "I also have this problem!"

While I appreciate that users have problems, them venting on the tool that Chromium developers use to get their work done actively prevents work from getting done. In addition, the emotion level on bugs like that tends to escalate until it ends up with posts about how Chromium developers are incompetent to not have fixed it by now, or don't care about their users to not have fixed it by now, etc.

That's why we lock bugs like that down. We track the importance of the issues to users with star counts, but the bug tracker isn't the place for discussions other than technical ones on how to fix things.

In any case, I've had my eye on  bug 456  for a while, but it wasn't until not too long ago that I had the inspiration about how to fix it (see the design document at http://bit.ly/project-oldspice ). We're testing these dialogs now, and I'm excited to see if it helps. I hope it does.