tkent@, are you interesting in driving this through deprecation and removal?

> tkent@, are you interesting in driving this through deprecation and removal?

I already have too many backlogs of sending intents :(

No worries, I can do it then.

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

commit 7bca5aabd14fb747ef1cfa083d181ec933707e7c
Author: foolip <foolip@chromium.org>
Date: Fri Nov 11 10:30:58 2016

Update legacycaller FIXMEs to reflect spec changes

legacycaller has been dropped for all but HTMLAllCollection in HTML:
https://github.com/whatwg/html/pull/203
https://github.com/whatwg/html/pull/1979

BUG= 465009 , 663662 
R=tkent@chromium.org

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

[modify] https://crrev.com/7bca5aabd14fb747ef1cfa083d181ec933707e7c/third_party/WebKit/Source/core/html/HTMLAllCollection.idl
[modify] https://crrev.com/7bca5aabd14fb747ef1cfa083d181ec933707e7c/third_party/WebKit/Source/core/html/HTMLEmbedElement.idl
[modify] https://crrev.com/7bca5aabd14fb747ef1cfa083d181ec933707e7c/third_party/WebKit/Source/core/html/HTMLFormControlsCollection.idl
[modify] https://crrev.com/7bca5aabd14fb747ef1cfa083d181ec933707e7c/third_party/WebKit/Source/core/html/HTMLObjectElement.idl

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

commit 0993fff22319c9a7f24bdf3bfcf4db1d8521a260
Author: foolip <foolip@chromium.org>
Date: Fri Nov 18 17:07:33 2016

Deprecate legacy callers for HTMLEmbedElement and HTMLObjectElement

Intent to Deprecate and Remove:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/AiDZ7ru9mGg/_D_9Fcc2AwAJ

BUG= 663662 

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

[modify] https://crrev.com/0993fff22319c9a7f24bdf3bfcf4db1d8521a260/third_party/WebKit/Source/bindings/core/v8/custom/V8HTMLPlugInElementCustom.cpp
[modify] https://crrev.com/0993fff22319c9a7f24bdf3bfcf4db1d8521a260/third_party/WebKit/Source/core/frame/Deprecation.cpp

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

commit 352682e3c9a3d4b9a6b2147e9b8573b449f71b37
Author: foolip <foolip@chromium.org>
Date: Tue Feb 14 01:23:01 2017

Remove legacy callers for HTMLEmbedElement and HTMLObjectElement

Intent to Deprecate and Remove:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/AiDZ7ru9mGg/_D_9Fcc2AwAJ

BUG= 663662 

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

[modify] https://crrev.com/352682e3c9a3d4b9a6b2147e9b8573b449f71b37/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/image-maps/image-map-processing-model/hash-name-reference-expected.txt
[delete] https://crrev.com/ecf5359e680e3e250b3317827fb0b1c774721f3c/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-embed-element/historical-expected.txt
[delete] https://crrev.com/ecf5359e680e3e250b3317827fb0b1c774721f3c/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-object-element/historical-expected.txt
[modify] https://crrev.com/352682e3c9a3d4b9a6b2147e9b8573b449f71b37/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-object-element/usemap-casing-expected.txt
[modify] https://crrev.com/352682e3c9a3d4b9a6b2147e9b8573b449f71b37/third_party/WebKit/Source/bindings/core/v8/custom/V8HTMLPlugInElementCustom.cpp
[modify] https://crrev.com/352682e3c9a3d4b9a6b2147e9b8573b449f71b37/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/352682e3c9a3d4b9a6b2147e9b8573b449f71b37/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/352682e3c9a3d4b9a6b2147e9b8573b449f71b37/third_party/WebKit/Source/core/html/HTMLEmbedElement.idl
[modify] https://crrev.com/352682e3c9a3d4b9a6b2147e9b8573b449f71b37/third_party/WebKit/Source/core/html/HTMLObjectElement.idl

I was just receiving this message: HTMLObjectElement legacy caller is deprecated and will be removed in M58, around April 2017

I discovered my problem and resolved it, but I was not trying to call an HTMLObjectElement as if it were a function.  My problem was that I had an onchange event where the function name was the same as the id attribute for the <object> (and its associated <input type="checkbox">).  It looked like this:

    <input  id="flipLR" onChange="flipLR()" type="checkbox"></input>
    <object id="flipLR" class="forLabel" data="icons/flipLR.svg"></object>

I solved the problem by renaming the function to "flipLeftRight()".  But I think this might reveal a bug in your implementation of this fix.  If it doesn't, then sorry for the distraction...

My code uses <objects> with SVG contents as if they were htmlFor labels for <input> elements.  The <svg> has the event handler this way:

    <svg onclick="top.iconClick(evt)">

The javascript for iconClick(evt) uses querySelector() to get the html input with the same id as the <svg>, then clicks it, like this:
    var input = document.querySelector(tagInput + selectID + id + endSelect);
    input.click()

The "deprecated feature" message happened on the input.click(), and the input was never clicked, it was considered an error and exited.

Hope this is useful!

#11: it's hard to confirm without a full page example, but I suspect that what was happening is that whenever that input changed, it was trying to call the object as a function, and as such your flipLR() function would never actually be called. Inside event handler scopes, the rules are very different, and elements with IDs have higher precedence than global function declarations.

I can provide a sample if it's of interest to you.  It would take me a few minutes to prepare, but wouldn't be too hard.  I'm OK with knowing about this as a restriction on my function names.  Yes, it seems that the function names and <object> ids are all in one table somewhere.  If that's normal and I simply need to know not to duplicate ids/function names, then I'm fine. If this is a bug and you want a sample, let me know.

#13, a sample would be good, but it'd also be great if you could check if your code behaves differently in Firefox, where one also cannot call these elements as functions.

I put together this guess about how your page works:
https://jsbin.com/juseqaj/edit?html,console,output

It'll start throwing an exception with the change. This sounds like the same problem you're seeing, and means that your flipLR() method was actually never called, instead you were invoking the object element as a method, which did nothing. If that's true, then just removing onChange="flipLR()" should preserve behavior, although that's obviously not what you had intended.

I'll put together a sample later today and post file files here.
I originally programmed this using Firefox as my test browser, and it called the function, not the object - it worked just fine.  Once I have the sample I'll test it in Firefox too.

Here is a sample.  Turns out it doesn't need any of the SVG to cause the failure, but it does need the object with the same id as the function. The checkbox alone with the same id does not cause the failure.  You can test this by simply removing the <object> from the .html file.

As I had remembered, it runs the function in Firefox, no failure.

I hope this helps...

Deleted: legacyCaller.html 481 bytes

legacyCaller.html 481 bytes View Download

#14 - re: "removing onChange=flipLR()" - as I said in my previous post, I have chosen to rename it, not remove it.  If this is a bug, then that's my temporary workaround.  If it's not a bug, then it's my permanent workaround for this naming restriction.

Renaming is a lot less radical than removing :-)

Greetings! I'm just checking in two weeks later to see if my sample exposes a bug or a feature. Thanks.

Oops, I should really look closer at this in case it exposes another bug that wasn't a problem before. Let me get back to this soon, in less than two more weeks!

OK, it looks like the problem is actually specific to when there are two elements with id="flipLR".

https://jsbin.com/pefirus/edit?html,output is a test that passes in Chrome, Edge and Safari, but fails in Firefox.

The relevant spec here is https://html.spec.whatwg.org/multipage/webappapis.html#getting-the-current-value-of-the-event-handler although I don't understand what it that explains the difference in scope rules in a script and in an event handler.

I've sent https://github.com/w3c/web-platform-tests/pull/5757 to add a test for this that should result in either Gecko changing or all other engines changing, depending on what actually makes sense.

I think that this issue should remain fixed though, we seem to now match Edge and Safari, and the workaround is to use a different ID.

#19/#20: If you're trying to make <object> NOT a function, then Firefox/Gecko is correct, right?  The failure in Firefox is a sign that the legacy caller issue is completely gone, right?
I'm just trying to make sure I understand this.  I realize that the spec is not specific on this point, but the Firefox implementation seems to make the most sense to me, given the fact that this behavior causes a failure in normally written code (code that does not try to use <object> as a function).  Your jsbin example is using <object> as a function, the exact legacy caller that you are trying to eliminate with this fix.

Or am I overreaching here?

...sorry for the add-on, but now I understand better the issue of two objects with the same id.  So if the <button> or <input> isn't there, then it doesn't happen? Very interesting.

At root this seems to be a problem with different scope rules, a problem that was exposed by this change but not introduced by it. I don't actually understand what exactly the rules are in the spec or in any implementation, I'm hoping the review of https://github.com/w3c/web-platform-tests/pull/5757 will reveal what needs to change for us to reach interoperability here.

A test for this has landed and I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1363374 for Gecko.