Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix deprecated event.returnValue in Chrome #1429

Closed
wants to merge 5 commits into from

Conversation

zhiyelee
Copy link
Contributor

As @hatched reported in #1417

chrome now issues a console warning
event.returnValue is deprecated. Please use the standard event.preventDefault() instead.

@juandopazo
Copy link
Member

You don't need to check if preventDefault is there in DOMEventFacade. YUI loads a specific script for IE where it uses returnValue: https://github.com/yui/yui3/blob/master/src/event/js/event-facade-dom-ie.js#L109-L111.

And from the API Docs:

returnValue String
sets the returnValue of the event to this value (rather than the default false value). This can be used to add a customized confirmation query to the beforeunload event).

So maybe we need to avoid returnValue in all events except for onbeforeunload.

e.preventDefault();
e.returnValue = returnValue || false;
if (e.preventDefault) {
e.preventDefault();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic here seems a bit flawed. Prior to your change, e.preventDefault was invoked without checking if said method actually existed. Therefore, your additional if statement will always evaluate to true.

preventDefault is manually attached to the Event object somewhere along the line...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right.
Sorry, I misunderstanded the code here, I have doubted why we have returnValue and preventDefault at the same time. Seems we set returnValue property here for other use which I am not familiar, and the preventDefault is always exist.

I will reread relative code,thanks for explaning.

@zhiyelee
Copy link
Contributor Author

@juandopazo I noticed the event-facade-dom-ie,but I didn't realized the usage relative to beforeunload in the comments far away from the function declare.

Thanks for explaning.

I also think avoid returnValue in all events except for onbeforeunload is a good idea. I will check it later.

@zhiyelee
Copy link
Contributor Author

hi @juandopazo, I have made a change

@zhiyelee
Copy link
Contributor Author

Ping..

@juandopazo
Copy link
Member

I'll get a reviewer to look at it Monday.

Meanwhile, can you please add a test to avoid regressions and a notice in the API docs?

@zhiyelee
Copy link
Contributor Author

@juandopazo Ok,I will make it later . Thx !

@ezequiel
Copy link
Contributor

ezequiel commented Dec 3, 2013

@juandopazo,

I don't see what value a notice to the API documentation would add in this case. It seems unusual and unnecessary to let the developer know about the deprecation of Event#returnValue, as they are not communicating directly with the DOM.

An additional unit test also seems unnecessary. All in all, what we we really care about is whether or not Event#preventDefault() still works properly after this change. I'm sure there are plenty of tests covering Event#preventDefault() already.


Ping @lsmith.

@@ -198,7 +198,9 @@ Y.extend(DOMEventFacade, Object, {
preventDefault: function(returnValue) {
var e = this._event;
e.preventDefault();
e.returnValue = returnValue || false;
if (e.type === 'beforeunload') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous assignment was simpler because it was harmless. It is still harmless (a warning is a minor nuisance, but not harmful).

I would prefer to keep the logic simpler and go with

if (returnValue) {
    e.returnValue = returnValue;
}

And let the browser complain when a developer writes dubious code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems a much better way and also avoid hardcode.

@lsmith
Copy link
Contributor

lsmith commented Dec 3, 2013

@ezequiel re: test coverage, sadly there are no tests of preventDefault(), let alone preventDefault(value) for DOM events.

It is worth adding a test for preventDefault(value).

@zhiyelee
Copy link
Contributor Author

zhiyelee commented Dec 4, 2013

@lsmith Sorry, I don't quite understand your meaning by land in, it seems changes can be seen in this PR https://github.com/yui/yui3/pull/1429/files

@lsmith
Copy link
Contributor

lsmith commented Dec 4, 2013

Weird. the commit wasn't showing on the PR for me, but now it is. My mistake.

@@ -158,7 +158,9 @@ Y.extend(DOMEventFacade, Object, {
preventDefault: function(returnValue) {
var e = this._event;
e.preventDefault();
e.returnValue = returnValue || false;
if (returnValue) {
e.returnValue = returnValue || false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The || false is unnecessary.

@lsmith
Copy link
Contributor

lsmith commented Dec 4, 2013

I'm ok with merging this even without new tests because the change in code functionality is obvious. The case where code is relying on e.returnValue in a non-IE environment is an edge case, and IMO does not need to be protected by the lib. That said, tests would be a nice bonus, given the currently limited coverage.

👍

@lsmith
Copy link
Contributor

lsmith commented Dec 4, 2013

To the committer that merges the change in, if @zhiyelee hasn't already pruned the unnecessary || false, please do so.

@zhiyelee, In case no one else has mentioned, it's easier for us to merge in PRs that contain only changes to files in the 'src' directory.

@zhiyelee
Copy link
Contributor Author

zhiyelee commented Dec 4, 2013

@lsmith Something wrong, I will close this and made another PR

@zhiyelee zhiyelee closed this Dec 4, 2013
@zhiyelee zhiyelee deleted the fix-returnvalue branch December 4, 2013 08:49
@zhiyelee
Copy link
Contributor Author

zhiyelee commented Dec 4, 2013

@lsmith I have pruned the unnecessary || false and made another PR that contain only changes to files in the srcdirectory #1460

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants