861947 - Random TypeError "Value does not implement interface Element"

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[arnaud]

We are experiencing random errors since the FF20 update : "TypeError: Value does not implement interface Element". 

The stack trace always point to the same line of code : `node.id.tagName` (from YUI3 `getId(node)` function [1]). The error occurs after some time using our webapp. After the first exception, every call to YUI getId() seems to fail.

We're still trying to find a way to produce a failing test case. We deployed a patch which wrap the line in a try/catch to log the `node` variable but since then the error doesn't seems to occur anymore.

What we know for now :

- `node.nodeType === 1` (Checked in the caller function [2])
- `console.log(node.localName)` == a, div, li... nothing  special
- We are able to catch the error higher up in the callstack (in an IndexedDB callback), but we are not sure if it starts from here.

Cheers,

Arnaud

[1] https://github.com/yui/yui3/blob/v3.8.0/src/dom/js/dom-core.js#L62-L63 
[2] https://github.com/yui/yui3/blob/v3.8.0/src/dom/js/selector-native.js#L220

Discussion on mozilla.dev.tech.dom : https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.tech.dom/qnzY0CpLvmw

Comment 1

[Boris Zbarsky [:bzbarsky]]

<a>, <div>, and <li> are all on WebIDL bindings in Firefox 20, looks like.

Is this just something you're seeing in error reports from users, or something that you're able to reproduce in builds you run yourself?

Comment 2

[arnaud]

Our users started reporting the error the day following the update to FF20. At first we were not able to reproduce the error on our dev build but we now have found a sequence of click which trigger the error from time to time. We have to repeat it a couple of time before the error starts happening.

Comment 3

[Peter Van der Beken [:peterv]]

Can you please describe the steps to reproduce or attach a testcase?

Comment 4

[arnaud]

We didn't find a simple testcase yet. I have created a demo account if you want to try, it will be deleted in one month.

1. Login on https://clicrdv.com/pro/login with [e-mail] / debugff20typeerror
2. Click on any of the calendar cell
3. On the right of the overlay, click on "Cliquez ici pour choisir la prestation" and select an item
4. Close the overlay by clicking on "Annuler" at the bottom
5. Repeat from the step 2 until the error occurs... It may take at least 5 iterations before the bug occurs

The bug occurs on my dev machine (Ubuntu 12.04 64bit - Firefox 20.0a2) or in a VM (Windows 7 from modern.ie with FF 20.0.1). We also have errors reported from OSX 10.6.

I hope to find a minimal testcase soon.

Thanks for your help

Comment 5

[Peter Van der Beken [:peterv]]

I tried reproducing but haven't managed to hit it after doing that about 20 times :-(.

Comment 6

[arnaud]

Did you have the debugger panel opened ? I noticed that the error does not happen in this case. Too bad I can't use the "pause on exception" option.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I haven't been able to reproduce it so far either, on Mac 10.8 (with either Firefox 20 or a nightly).  I was using a clean profile, nothing special opened....

Comment 8

[Maxime RETY]

Hi,

I'm a co-worker of Arnaud.

Since JIT was mentioned in the discussion on mozilla.dev.tech.dom, I played with the JIT-inspector profiler (https://addons.mozilla.org/fr/firefox/addon/jit-inspector/) until having the TypeError "Value does not implement interface Element".

Below are the info I gathered around the failing line of code "node.id.tagName". I don't know if it's of interest to you because it is all Greek to me.

It seems that no optimization about the getId function is reported under the IonActivity category before the TypeError is raised. Once the TypeError has been raised, we get the following information (sorry about the ugly copy&paste):


IonActivity:

function (node) {
        var id;    #0
        console.log("node=" + node + " tagName=" + node.tagName + " id=" + node.id);
        if (node.id && !node.id.tagName && !node.id.item) {    #2
Block #2 -> #3 -> #4 :: 3 hits
[MoveGroup]
[GetPropertyCacheV]
jmp        ((1170))
[OsiPoint]
[TypeBarrier]
movq       %rcx, %rdx
shrq       $47, %rdx
cmpl       $0x1fff5, %edx
je         ((1189))
cmpl       $0x1fff7, %edx
jne        ((1201))
movabsq    $0x7fffffffffff, %rdx
andq       %rcx, %rdx
movq       0x8(%rdx), %rdx
movabsq    $0x162702400, %r11
cmpq       %r11, %rdx
je         ((1237))
jmp        ((1242))
##link     ((1237)) jumps to ((1242))
##link     ((1189)) jumps to ((1242))
[Pointer]
movabsq    $0x16276a610, %rdx
[GuardShape]
movabsq    $0x16361f0d8, %r11
cmpq       %r11, 0(%rdx)
jne        ((1271))
[Pointer]
movabsq    $0x16276a610, %rdx
[StackArgV]
movq       %rcx, 0x8(%rsp)
[CallNative]
addq       $0x8, %rsp
movabsq    $0xfffb80016360f3c0, %r11
push       %r11
movabsq    $0x106002000, %rax
movq       0x34ac8(%rax), %rax
xorl       %edi, %edi
movq       %rsp, %rbx
push       %rdi
movabsq    $0xffffffffffffffff, %rcx
pushl      $0x280
push       %rcx
movabsq    $0x106002000, %r11
movq       %rsp, 0x34ac0(%r11)
pushl      $0x0
pushl      $0x0
movq       %rsp, %rcx
andq       $0xfffffff0, %rsp
push       %rcx
subq       $0x8, %rsp
movq       %rbx, %rdx
movq       %rdi, %rsi
movq       %rax, %rdi
movabsq    $0x101fd6820, %rax
call       *%rax
addq       $0x8, %rsp
pop        %rsp
testl      %eax, %eax
je         ((1414))
movq       0x28(%rsp), %rcx
jmp        ((1424))
##link     ((1414)) jumps to ((1424))
subq       $0x8, %rsp
movq       %rsp, %rax
movq       %rsp, %rcx
andq       $0xfffffff0, %rsp
push       %rcx
subq       $0x8, %rsp
movq       %rax, %rdi
movabsq    $0x102969400, %rax
call       *%rax
addq       $0x8, %rsp
pop        %rsp
movabsq    $0xfffa00000000000f, %rcx
movq       0x0(%rsp), %rsp
ret
##link     ((1424)) jumps to ((1478))
addq       $0x28, %rsp
[MoveGroup]
[Nop]
[OsiPoint]
[TypeBarrier]
movq       %rcx, %rax
shrq       $47, %rax
cmpl       $0x1fff2, %eax
je         ((1501))
cmpl       $0x1fff5, %eax
je         ((1513))
jmp        ((1518))
##link     ((1513)) jumps to ((1518))
##link     ((1501)) jumps to ((1518))
[NotV]
movq       %rcx, %r11
shrq       $47, %r11
cmpl       $0x1fff2, %r11d
je         ((1538))
cmpl       $0x1fff6, %r11d
je         ((1551))
cmpl       $0x1fff3, %r11d
jne        ((1564))
testl      %ecx, %ecx
je         ((1572))
jmp        ((1577))
##link     ((1564)) jumps to ((1577))
cmpl       $0x1fff1, %r11d
jne        ((1590))
testl      %ecx, %ecx
je         ((1598))
jmp        ((1603))
##link     ((1590)) jumps to ((1603))
cmpl       $0x1fff7, %r11d
je         ((1616))
cmpl       $0x1fff5, %r11d
jne        ((1629))
movabsq    $0x7fffffffffff, %r11
andq       %rcx, %r11
movq       0x0(%r11), %r11
shrq       $4, %r11
testq      %r11, %r11
je         ((1658))
jmp        ((1663))
##link     ((1629)) jumps to ((1663))
movq       %rcx, %xmm0
xorpd      %xmm15, %xmm15
ucomisd    %xmm0, %xmm15
je         ((1684))
jmp        ((1689))
##link     ((1684)) jumps to ((1689))
##link     ((1658)) jumps to ((1689))
##link     ((1598)) jumps to ((1689))
##link     ((1572)) jumps to ((1689))
##link     ((1551)) jumps to ((1689))
##link     ((1538)) jumps to ((1689))
movl       $0x1, %rax
jmp        ((1699))
##link     ((1689)) jumps to ((1699))
##link     ((1663)) jumps to ((1699))
##link     ((1616)) jumps to ((1699))
##link     ((1603)) jumps to ((1699))
##link     ((1577)) jumps to ((1699))
xorl       %eax, %eax
##link     ((1699)) jumps to ((1701))
[TestVAndBranch]
movq       %rcx, %r11
shrq       $47, %r11
cmpl       $0x1fff2, %r11d
je         ((1721))
cmpl       $0x1fff6, %r11d
je         ((1734))
cmpl       $0x1fff3, %r11d
jne        ((1747))
testl      %ecx, %ecx
je         ((1755))
jmp        ((1760))
##link     ((1747)) jumps to ((1760))
cmpl       $0x1fff1, %r11d
jne        ((1773))
testl      %ecx, %ecx
je         ((1781))
jmp        ((1786))
##link     ((1773)) jumps to ((1786))
cmpl       $0x1fff7, %r11d
jne        ((1799))
movabsq    $0x7fffffffffff, %rbx
andq       %rcx, %rbx
movq       0x0(%rbx), %rdx
movq       0x0(%rdx), %rdx
movq       0x0(%rdx), %rdx
movabsq    $0x10365e870, %r11
cmpq       %r11, %rdx
je         ((1840))
movabsq    $0x10365ea28, %r11
cmpq       %r11, %rdx
je         ((1859))
movabsq    $0x1036895c8, %r11
cmpq       %r11, %rdx
je         ((1878))
testl      $0x40, 0x8(%rdx)
je         ((1891))
jmp        ((1896))
##link     ((1799)) jumps to ((1896))
cmpl       $0x1fff5, %r11d
jne        ((1909))
movabsq    $0x7fffffffffff, %r11
andq       %rcx, %r11
movq       0x0(%r11), %r11
shrq       $4, %r11
testq      %r11, %r11
je         ((1938))
jmp        ((1943))
##link     ((1909)) jumps to ((1943))
movq       %rcx, %xmm0
xorpd      %xmm15, %xmm15
ucomisd    %xmm0, %xmm15
je         ((1964))
jmp        ((1969))

            id = node.id;
        } else if (node.attributes && node.attributes.id) {
            id = node.attributes.id.value;
        }
        return id;
    }



JMActivity:

!node.id.tagName :: not :: interp: 248 mjit: 33983 mjit_calls: 33983 mjit_code: 2072963 arith_unknown: 33983

node.id.tagName :: getprop :: interp: 248 mjit: 33983 mjit_calls: 33983 mjit_code: 20762603 infer_di: 33983 infer_barrier: 33983 observe_undefined: 33317 observe_string: 666 prop_other: 33983

node.id :: getprop :: interp: 248 mjit: 33983 mjit_calls: 33983 mjit_code: 21171409 infer_poly: 33983 infer_barrier: 33983 observe_string: 33317 observe_object: 666 prop_other: 33983


- 
Maxime

Comment 9

[arnaud]

Oh I'm sorry, we patched YUI getId method yesterday at 11am PDT to remove the code which produced the error (node.id.tagName).

I've just reverted this patch specifically on the demo account and added console.log. The error continues to happen on FF20 with a fresh profile : http://www.youtube.com/watch?v=4lP_0XEETGc

Here is the output of the console https://gist.github.com/ArnaudD/5404004/raw/04c3ec3b2b95ed4d76c72275654b3525af9a7197/console.log The patch is a simple `eval` so line numbers don't match. You can find the code here https://gist.github.com/ArnaudD/5404035

I tried to reproduce the error on FF21 and nightly but nothing happened. This bug seems specific to FF20.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Maxime, thanks for the jit inspector output.  That looks like it's doing a generic call to the getter, which is at least consistent with the exception.

arnaud, thanks for updating the demo.  Now I can definitely reproduce with Firefox 20.  Let me see what I can figure out about it, just to make sure it's really fixed in 21 and not just masked.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So, I've managed to reproduce this _once_ in a debug Firefox 20 build.  When I got the exception, we were calling the tagName getter... and the this object was a String(!).

Comment 12

[Boris Zbarsky [:bzbarsky]]

Alice, do you have time to find the fix range for this on trunk?  I assume the regression range is when we converted Element to WebIDL bindings....

Comment 13

[Alice0775 White]

(In reply to Boris Zbarsky (:bz) from comment #12)
> Alice, do you have time to find the fix range for this on trunk?  I assume
> the regression range is when we converted Element to WebIDL bindings....

Could you provide Detailed STR?
Does this only happens in Firefox20?

Comment 14

[Boris Zbarsky [:bzbarsky]]

STR are in comment 4.  And yes, so far the claim is only Firefox20, so presumably fixed sometime in the 21 cycle...

Comment 15

[Alice0775 White]

Fixed window(m-c)
Bad:
http://hg.mozilla.org/mozilla-central/rev/a3effbaa10bb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130108 Firefox/21.0 ID:20130108102120
Fixed:
http://hg.mozilla.org/mozilla-central/rev/7bce868864bf
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130109 Firefox/21.0 ID:20130109002633
Fixed pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a3effbaa10bb&tochange=7bce868864bf


Fixed window(cached m-i)
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/999039502afb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130108 Firefox/21.0 ID:20130108092121
Fixed:
http://hg.mozilla.org/integration/mozilla-inbound/rev/3a5db98b87e4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130108 Firefox/21.0 ID:20130108103119
Fixed pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=999039502afb&tochange=3a5db98b87e4

Bug 799252 fixes the problem ?

Comment 16

[Boris Zbarsky [:bzbarsky]]

More likely, bug 827659.

Jan, is it expected that without that bugfix we could end up calling a random DOM getter on a string (when in reality the string doesn't even have a property with that name)?  And if so, does the patch there just paper over that situation (us finding the wrong getter!) or actually fix it somehow?

Comment 17

[Jan de Mooij [:jandem]]

(In reply to Boris Zbarsky (:bz) from comment #16)
> Jan, is it expected that without that bugfix we could end up calling a
> random DOM getter on a string (when in reality the string doesn't even have
> a property with that name)?  And if so, does the patch there just paper over
> that situation (us finding the wrong getter!) or actually fix it somehow?

The problem was that we looked at type information for all possible objects, see they all have the same getter/setter, and emit a direct call to that getter/setter, *even if the value could be a primitive*. Bug 827659 fixed this by adding an is-object guard if primitive types are possible.

This is the exact same issue. Sorry I forgot to request approval for Firefox 20..

Comment 18

[Boris Zbarsky [:bzbarsky]]

Ah, I see.  So we looked at all possible objects in the typeset but ignored that there might have been non-objets in the typeset too?  Fun.

So that explains what's going on in this bug: once this function gets ion-compiled (which only happens after a large number of iterations, which is why you have to repeat the steps a few times), bad things happen...

We're going to ship the fix in Firefox 21; not sure whether it's worth doing an extra release of 20 for this.  Is there one planned anyway?

Comment 19

[Alex Keybl [:akeybl]]

(In reply to Boris Zbarsky (:bz) from comment #18)
> We're going to ship the fix in Firefox 21; not sure whether it's worth doing
> an extra release of 20 for this.  Is there one planned anyway?

Nope, 20.0.1 is already out the door. But we can keep it on the tracking nom list in case.

Comment 20

[Maxime RETY]

Attachment: test case for bug 861947

Comment 21

[Maxime RETY]

It's a bit late, but I've just added a test case that demonstrates this issue in a simpler context than our application.

Thank you all for the upcoming fix in Firefox 21.

Comment 22

[Frank Yan (:fryn)]

Now (in Nightly and trunk), HTMLElement.prototype.style throws:
TypeError: Value does not implement interface HTMLElement

Comment 23

[Boris Zbarsky [:bzbarsky]]

> HTMLElement.prototype.style throws:

It's supposed to since HTMLElement.prototype is not an HTMLElement.

It sounds like this bug itself is wontfix for Firefox 20 but fixed in 21.  I have no idea how to resolve it properly; let's call it fixed.