Re: Bug 641509
On 2014-01-07 6:39 AM, matteosistise...@gmail.com wrote: On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the comments I can't see any valid argument that backs up the decision to not fix the issue. At least none that would stand to the objection which I posted as a comment: Having a standard message always displayed is ok, but what's the reasoning behind not allowing to _add_ a custom text?!?!?!? [Note to list: I think this is an honest question which deserves a straight answer, and although I suspect the answer I'm about to give is somewhere in Bugzilla, I can't blame the poster for overlooking it in a giant bug thread full of shouting.] I am not the person who made this decision, but I agree with it, and this is why. If we allow the page to customize the onbeforeunload confirmation box _at all_, a malicious page can - just with clever wording - confuse the user into misunderstanding the standard message. The standard message we have right now is pretty hard to misunderstand, but we have actually seen things like "IF YOU PRESS "LEAVE PAGE" YOUR COMPUTER WILL CRASHone!" in the wild, and we have support tickets saying people were actually scared by that sort of thing. It's also conceivable that a malicious page could use Unicode trickery to render the standard message unreadable; we *might* be able to prevent that, but we would never be sure we had gotten every single way. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 641509
On 1/7/2014, 11:40 AM, Matteo Sisti Sette wrote: Oh now I see, 'the *confusion* of the "OMG YOUR COMPUTER IS INFECTED BY A VIRUS" messages were causing', that's the point! LOL Yeah, I think we're done here. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 641509
On 07/01/14 13:02, Till Schneidereit wrote: The discussion has happened in bug 588292[1]. For a succinct summary, see tha bug's comment 37[2]. No, that doesn't respond to my point. 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? Oh 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. 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 641509
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. > Oh 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
Re: Bug 641509
On Tue, Jan 7, 2014 at 11:39 AM, wrote: > Can anybody explain not only to me but also to the number of people who > questioned the same, why the decision to not fix the issue is a good idea? > (despite by the way every other browser supporting that, except Opera which > does not support the onbeforeunload event in the first place) We support the event, we do not support modifying the message shown to the user to prevent spoofing, as explained in the bug. This is perfectly acceptable per the standard that defines the event: http://www.whatwg.org/specs/web-apps/current-work/#prompt-to-unload-a-document -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 641509
The discussion has happened in bug 588292[1]. For a succinct summary, see tha bug's comment 37[2]. For the reasoning behind restricting comments, see that bug's comment 116[3] In general, it's very unlikely that a basic point as the one you made wasn't considered in a discussion spanning 230 comments in two bugs (plus some duplicates), so not getting a response to it isn't any more unreasonable than not reading up on the bug's history before commenting. In comment 82[4] of the bug you commented on, Justin points out that considerable deliberation has happened before this change. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=588292 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=588292#c37 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=588292#c116 [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=641509#c82 On Tue, Jan 7, 2014 at 12:39 PM, wrote: > On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the comments I > can't see any valid argument that backs up the decision to not fix the > issue. > At least none that would stand to the objection which I posted as a > comment: > > > Having a standard message always displayed is ok, > > but what's the reasoning behind not allowing to _add_ a custom > text?!?!?!? > > In "reply" to my comment the issue was closed to comments. > > Instead of that, could anybody reply with a reasonable argument and prove > my "reasoning" wrong? (I put "reasoning" between quotes because I find it > almost too elementary and obvious to be even called a "reasoning") > > Can anybody explain not only to me but also to the number of people who > questioned the same, why the decision to not fix the issue is a good idea? > (despite by the way every other browser supporting that, except Opera which > does not support the onbeforeunload event in the first place) > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Bug 641509
On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the comments I can't see any valid argument that backs up the decision to not fix the issue. At least none that would stand to the objection which I posted as a comment: > Having a standard message always displayed is ok, > but what's the reasoning behind not allowing to _add_ a custom text?!?!?!? In "reply" to my comment the issue was closed to comments. Instead of that, could anybody reply with a reasonable argument and prove my "reasoning" wrong? (I put "reasoning" between quotes because I find it almost too elementary and obvious to be even called a "reasoning") Can anybody explain not only to me but also to the number of people who questioned the same, why the decision to not fix the issue is a good idea? (despite by the way every other browser supporting that, except Opera which does not support the onbeforeunload event in the first place) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform