We're getting a bit far afield here, but there's no conflict with the spec. The returnValue description you quote is an authoring guideline. The requirements for user agents (described at http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#unloading-documents) don't include displaying the provided string to the user (just "The prompt shown by the user agent may include the string of the returnValue attribute").
Gavin On Thu, Jan 9, 2014 at 3:44 PM, Axel Hecht <[email protected]> wrote: > I did a bit of investigation on those bugs, and I noticed three things: > > - for the alert etc APIs during onbeforeclose, we uplifted our changes to > the html5 spec > - we did listen to the complaints about our change, but we disagree with the > arguments > - I don't find a track record of us trying to uplift our stance on the > return value on onbeforeclose to the html5 spec > > The latter bothers me a bit, and I'd be happy if someone could point to a > discussion for that. > > The spec doesn't use a very precise language, > http://www.w3.org/html/wg/drafts/html/master/browsers.html#beforeunloadevent > says > >> The |returnValue| attribute represents the message to show the user. > > > It's not a MUST or SHOULD, apparently it'd benefit the discussion if that > was clear. > > I'm not arguing either way, but I do think we should attempt get the spec > and our implementation in sync. > > Axel > > > On 1/9/14 11:50 AM, [email protected] wrote: >> >> I do not know if this is the proper forum for this question, or even if >> the proper forum exists. >> >> But in 2011, a poor decision was made, whcich fixed a security problem and >> created a usability issue. A bug was opened, with overwhelming oposition to >> the developers decision. Many comments followed with lots are good arguments >> why this "fix" was poor decision. The comments also included a better, easy >> to implement fix that was both secure AND good for users. There is no reason >> not to implement it. >> >> The developer ignored all the comments (over 100 comments in favour of >> change!) and did not reply. 3 days ago, comments were closed. >> >> What I would like, is to call a vote on this issue. If the majority >> supports the better fix (and so far it 100 in favour and 1 against, based on >> thread comments), and there is no security issue created (based on the >> arguments in the comments, there is no) then this change should be >> implemented. >> >> How can we call a vote? How can we appeal? >> >> Please see: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=641509 >> https://bugzilla.mozilla.org/show_bug.cgi?id=619857 >> https://bugzilla.mozilla.org/show_bug.cgi?id=643141 >> https://bugzilla.mozilla.org/show_bug.cgi?id=652103 >> https://bugzilla.mozilla.org/show_bug.cgi?id=656235 >> https://bugzilla.mozilla.org/show_bug.cgi?id=780444 >> https://bugzilla.mozilla.org/show_bug.cgi?id=784630 >> >> and: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=956988 >> https://bugzilla.mozilla.org/show_bug.cgi?id=957972 > > > _______________________________________________ > governance mailing list > [email protected] > https://lists.mozilla.org/listinfo/governance _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
