New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 659911 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Nov 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

onload event is triggered twice

Reported by hs85je...@gmail.com, Oct 27 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce the problem:
1. Open with attached 'loadEvent.html'
2. Watch the Console.

What is the expected behavior?
Print the "body" in the console.

What went wrong?
Print the "window" and "body" in the console.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 54.0.2840.71  Channel: stable
OS Version: OS X 10.12.0
Flash Version: Shockwave Flash 23.0 r0

I think the onload function of the <body> overwrites the defined window.onload in the <script> of the <head>. But two logs is prited in the console. In my investigation, EventTarget::getAttributeEventListener() fails to find the same event listener because listener->belongsToTheCurrentWorld() return false.
 
loadEvent.html
149 bytes View Download

Comment 1 by tkent@chromium.org, Oct 27 2016

Components: -Blink>DOM Blink>Loader
Status: Untriaged (was: Unconfirmed)
Confirmed that only "body" is printed with Safari and Firefox.

Comment 3 by sigbjo...@opera.com, Nov 10 2016

Owner: sigbjo...@opera.com
Project Member

Comment 4 by bugdroid1@chromium.org, Nov 11 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/05c2d71f2c3cab4c40c3d775b304d0bbfbd166bd

commit 05c2d71f2c3cab4c40c3d775b304d0bbfbd166bd
Author: sigbjornf <sigbjornf@opera.com>
Date: Fri Nov 11 06:34:16 2016

Support fetching attribute listeners from outside v8 context scopes.

A number of the <body> element's event handler attributes represent
and expose event handlers on the window object, hence the parser
will update & replace attribute event listeners while parsing the
attributes. This may well happen while executing outside any v8
context; adjust the lookup of attribute event listeners
to support such usage.

R=haraken
BUG= 659911 

Review-Url: https://codereview.chromium.org/2492793002
Cr-Commit-Position: refs/heads/master@{#431509}

[add] https://crrev.com/05c2d71f2c3cab4c40c3d775b304d0bbfbd166bd/third_party/WebKit/LayoutTests/fast/events/onload-body-replace-expected.txt
[add] https://crrev.com/05c2d71f2c3cab4c40c3d775b304d0bbfbd166bd/third_party/WebKit/LayoutTests/fast/events/onload-body-replace.html
[modify] https://crrev.com/05c2d71f2c3cab4c40c3d775b304d0bbfbd166bd/third_party/WebKit/LayoutTests/imported/wpt/html/webappapis/scripting/processing-model-2/compile-error-in-body-onerror-expected.txt
[modify] https://crrev.com/05c2d71f2c3cab4c40c3d775b304d0bbfbd166bd/third_party/WebKit/Source/bindings/core/v8/V8AbstractEventListener.cpp
[modify] https://crrev.com/05c2d71f2c3cab4c40c3d775b304d0bbfbd166bd/third_party/WebKit/Source/bindings/core/v8/V8AbstractEventListener.h
[modify] https://crrev.com/05c2d71f2c3cab4c40c3d775b304d0bbfbd166bd/third_party/WebKit/Source/core/events/EventListener.h
[modify] https://crrev.com/05c2d71f2c3cab4c40c3d775b304d0bbfbd166bd/third_party/WebKit/Source/core/events/EventTarget.cpp

Comment 5 by sigbjo...@opera.com, Nov 11 2016

Status: Fixed (was: Untriaged)

Comment 6 by sigbjo...@opera.com, Nov 11 2016

Thanks for a fine bug report, btw - couldn't be better :)

Comment 7 by hs85je...@gmail.com, Nov 11 2016

Thanks for a bug fixing.

I'm newbie on the chromium.

If I have a chance to fix a bug, I will try to fix it myself.

2016. 11. 11. 오후 4:27에 "sigbjo… via monorail" <monorail+v2.1813599968@
chromium.org>님이 작성:
This change seems contrary to the standard, as far as I can tell:

https://html.spec.whatwg.org/multipage/webappapis.html#handler-onload

The spec says the onload event handler should be:

supported by all Window objects, as event handler IDL attributes on the Window objects themselves, and with corresponding event handler content attributes and event handler IDL attributes exposed on all body and frameset elements that are owned by that Window object's associated Document

Note the "and", nor "or".

This change breaks some code we have
https://bugs.chromium.org/p/chromium/issues/detail?id=687343

Comment 9 by phistuck@gmail.com, Feb 1 2017

#8 -
I doubt it is contrary to the specification. The specification just says that the IDL attributes (and so on) should be on all of them, it does not talk (in this specific paragraph) about what overrides what when it is set. Since those events do not bubble (they do not really fire on <body>), but are actually the same event handler, this seems correct.

There is a reason all (Firefox, Safari, Edge, Internet Explorer, Chrome) of the (major?) browsers agree at the moment.
Also, note that even if the specification is really not reflecting the reality at the moment (allowing multiple handlers), it will probably be changed to reflect the reality (multiple handlers override).

To summarize, I advise you to change your code (and not use inline HTML event handlers or onfoo attributes anyway!).
#8, in terms of spec you also want to be looking at:

 * https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers
 * https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-content-attributes

The setting of an event handler {IDL,content} attribute will install it as the handler, replacing any previous. An event handler's value range is either null or a function object.

Sign in to add a comment