My point is that your arguments have been brought forward in the discussion, and your post didn't bring anything new to the table. You might disagree with the decision the contributors and owners of the affected module have come to, and that's your right.
Snide remarks and shooting down exaggerated strawman versions of their arguments, however, won't help you reverse this decision. If anything, a well thought-out argument put forward in a reasonable way would. Keep in mind that this argument should contain something not yet mentioned in the discussion. Otherwise it has very slim chances of reverting a decision that stood regardless of previous counterarguments for years now. On Tue, Jan 7, 2014 at 5:40 PM, Matteo Sisti Sette < matteosistise...@gmail.com> wrote: > I did read the discussion in the bug I commented on (not the other one I > admit) and the "security reasons" argument is flawed in that it assumes > that the author-provided text would REPLACE the standard warning text, > while in fact the requested fix (and what EVERY other browser does) is to > ADD the text provided by the site to the standard warning provided by the > browser. How can that possibly be a security concern? > People disagree with your assessment, clearly. > Ohhhhh now I see, 'the *confusion* of the "OMG YOUR COMPUTER IS INFECTED > BY A VIRUS" messages were causing', that's the point! LOL!!!! > > Then based on that we shouldn't allow the browser to open a web page at > all, because it could contain that kind of message. Or, to be a little less > extreme and sarchastic, we should definitely disallow arert() based on that > exact same argument. > Note, by the way, that alert() _had_ been a security concern in the old > days and a solution was sought and found, without having to drop the > feature completely. Think about that. > As pointed out above, your chances of getting people to actually think about the merits of what you're saying would be vastly higher if you didn't ridicule them or sarcastically misrepresenting their arguments. > By the way I see the behavior every other browser implements described > here: > http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html > Not sure but that may mean that perhaps it might some day end up being > included in the standards..... > Step 8 of what Anne linked to earlier explicitly specifies that displaying a custom message is optional: "The prompt shown by the user agent may include the string of the returnValue attribute, or some leading subset thereof. (A user agent may want to truncate the string to 1024 characters for display, for instance.)" _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
