It's 2016 and Microsoft is incapable of creating a reliable cross-site login system. Instead, we still have the disastrous mess that is live.com. Minimum 2 redirects - at least 1 of which is Javascript (seriously?) - to handle a simple login. And when your cookies go a bit wonky, you won't even be able to browser the MSDN site to look up technical details. You have to manually clear your cookies. Again.
This infuriates me. It also really screws with people who can't touch type, and thus don't realize it's happened until they look up after entering their password only to realize the page changed and their text was lost.
I presume what's going on is the site realizes the login won't work and redirects you to the domain where it will, but it's just terrible design all around.
Input your email / password -> select if you want to use your personal or business profile -> enter your login info again (because, reasons) -> go through two redirects.
Might it be some attempt to disspel censorship, such as the scenario you're describing?
On a slightly related note, I really hate that we Internet Citizens are convicted to using plaintext server name indication.
Modal dialogue boxes are for lazy programming not for UI. Almost nothing in real life is modal. Don't break a user's flow! We just built a full application platform (i.e. dev kit, apps, application environment, etc.) and nothing is model, not one thing. Errors are added to a notification list that a user can look at at any time. Data merge conflicts are resolved via automatic default branching that the user can override later. Data is copy on write, and versions are retained. Login is handled with PKI.
Modal is forbidden on our platform period. If an app breaks this some how and finds a way to hack a modal event, we will treat this as a DOS attack and remove the app and ban the developer. We believe the user is the final authority, not the programmer, or the platform.
(obviously this is a bit of a pet peeve for me)
I like the cut of your jib!
I wholeheartedly agree: modal dialogs are demon spawn. A throwback to the single-threaded Mac that freezes the entire operating system even while you have a menu popped up.
A full-screen, in page overlay, in red, with a clear, black-on-white dialog stating what you were about to do and requesting confirmation.
It's obvious. It's user-centric. It doesn't affect other browser tabs. And they don't abuse it for other functions (nags, etc.).
In fact, I cannot name a single one. Open/save file dialogue? Emacs minibuffers are light years ahead of the current Windows crap.
Asking for credentials? Same thing, only grey out the controls that directly depend on credentials and use something like emacs minibuffer for entry, not a new window on top of the rest of the form.
And, while I'm still on it - don't EVER grey out anything without an explanation. I want to be able to hover over a greyed out control and see a detailed explanation immediately. Not doing this is rude.
If a UI designer cannot build a seamless handling of all the exceptional cases into a flow, he'd better move on to a simpler job (I don't know - programming, sweeping streets, packing groceries, whatever) and let the professionals do the work instead.
Also, most (if not all) frameworks implement modal dialogues in a very ugly way. For example, in Visual Studio it is a very often case when you may want to copy and paste something from some other editor window into a modal dialogue. But you cannot - it's all locked! Such things are extremely annoying and totally unacceptable.
Modern browsers are capable of running separate JS contexts, but doing so breaks backwards compatibility in a corner case: if you have the same domain open in two tabs, an alert() on one should block processing in the other. Otherwise, interacting with the other could change shared JS state while the code assumed it was blocked.
Concerns about this led to many discussions about designs where you would need to mark all tabs that were grouped together into blocks waiting for the modal to close, which are very difficult for users to understand. (I never quite understood why this hypothetical race was such a worry but people who knew more about web compat than me said that it was actually important, that sites relied upon this.)
They share cookies, sure, but that's a very different thing that JS interpreter state.
But I've never heard anything about an alert in one tab blocking the JS interpreter of another tab on the same site, as that would certainly break the principle of least astonishment. Where is that behavior documented?
So why don't we make the tradeoff and break these corner case websites in order to fix a far worse problem? Backwards compatibility > * is too high of a standard.
It wouldn't make a lot of sense in practicality, but would be interesting to use alert() to block js execution, or even some of these olders legacy feature sets.
They've also been restyled to make it obvious they're a prompt from the website not from safari itself.
Also, there are legitimate uses for this functionality, so as with many things I think the solution is not to remove the functionality, just improve the implementation.
Firefox does this too.
Mode 1: Render static content; allow unobtrusive JavaScript operations (perhaps capped by total operations or CPU usage).
Mode 2: Run unlimited JS operations, allow alert() and window.onbeforeunload events handers.
The second mode could be called "Application Mode" and could be turned on selectively per site.
This would allow you to give gmail.com whatever resources it needed. But clickbait-headline-slideshows.com could not, unless you explicitly allowed it.
This has gotten a little more difficult since chrome changed the UI around these settings though.
1. Reading/commenting mode. 2. Applications 3. Commerce. 4. A/V media.
The're four distinct use cases, with four distinct client requirements (and/or isolation requirements).
uMatrix buys you some of the JS isolation you're looking for.
https://www.reddit.com/r/dredmorbius/comments/256lxu/tabbed_...
I wrote up a similar proposal a few months ago, didn't get much love: http://www.eggplant.pro/blog/proposal-safeweb/
Not that there aren't ways to fix this, but in general "remove the offending API" rarely works on the Web. You need a more subtle approach.
It might not amount to good UX practices but it's not malware or a dark pattern either.
Besides, if at all possible most browser vendors try to be backward compatible. There are many applications out there that make ample use of pop-up dialogues. There's no need to break those just because they don't provide a stellar UX.
Sorry, I disagree with you. On a typical non-web application, a modal dialog doesn't prevent me from accessing other applications. It doesn't prevent me from forcefully killing crapware either. The idea that web applications should be able to break user expected control at the browser level is silly.
Browsers have Back, Forward, Refresh, Stop buttons, Tabs, cookie prefs, DNT prefs etc. Anything contained in a browser should respect these things. Browser devs should enforce this as browsers become more and more like their own operating systems.
If you want websites to be able to be dynamic at all, then they can use that power to be annoying. Two sides of the same coin.
(the history thing seems like it might be more addressable)
Our web app autosaves so the dialog box should never appear, but our metrics show that it appears surprisingly often -- sometimes it can take a few seconds for changes to flush through the websocket, and for the save to get acknowledged.
If you took that away, our users would lose changes. I imagine they would get pretty irate.
I don't see how any of the "excuses" in other people's comments would preclude something like that allowing people to easily escape an evil site like you describe.
At the end of the day, I think it is not that easy to say, what is a "bad behavior". Somebody can consider showing advertisment as a bad behavior. In many cases you can communicate with authors of a website and tell them your opinions, or stop wisiting that website (which is also a form of communication, authors will know that something is wrong when they lose visitors).
The worst things a browser can do come from javascript, so having a whitelist is useful. Remove anyone from your whitelist that is engaging in behavior you disapprove of.
I don't let facebook run scripts on my machines because I disagree with their philosophy of selling user data to the highest bidder, and tracking everything users do. That's too intrusive so I simply disallow them access.
No site that calls in too many javascript packages is given any privs on my computer.
