javascript - Webkit Mutation Observer callback not triggered when select box attribute's change - Stack Overflow

admin管理员组

文章数量:1356878

I am trying to monitor changes to select box (or nested option elements) with new Mutation Observer functionality. However, only "setAttribute" is triggering mutation observer's callback for me.

Here's the code I am using:

~function(doc, $) {
    var select = $('select');

    // 
    var observer = new WebKitMutationObserver(function(mutations) {
        alert(mutations.length + " mutations happened");
    });

    observer.observe(select, {
        // monitor descendant elements – changing `selected` attr on options
        subtree: true,
        attributes: true
    });

    // this triggers Observer's reaction, but doesn't update select box UI
    select.setAttribute('value', 'whee'); 
    // this updates select box UI, but doesn't trigger mutation observer's callback
    select.value = "whee";
    // this also updates the UI, but doesn't trigger mutation observer's callback
    select.getElementsByTagName('option')[0].selected = true;
    //
    // neither does manual selecting of options trigger mutation observer unfortunately :(

    button.addEventListener('click', function(e) {
        e.preventDefault();
        // my goal is to react to this change here 
        select.value = Math.random() > .5 ? "whee" : "whoa";
    }, false);

}(document, function(selector) { return document.querySelector(selector); });​

And here's this code in action /

I would like to react to changes to attributes (selected on <option> or value on <select>), any suggestion on why observer doesn't react is more than wele!

I am testing this in Chrome 18.0.1025.168 on Mac OS X. Production code would of course also have a moz prefix for the constructor and unprefixed version too, this is testing code.

UPD.

Tested the code in Firefox Nightly too and it behaves the same way as in Chrome, as well as in Chrome Canary. I have filled the bug for both browsers:

• .cgi?id=757077

Please ment and vote for these bugs if you also find this problem annoying.

I am trying to monitor changes to select box (or nested option elements) with new Mutation Observer functionality. However, only "setAttribute" is triggering mutation observer's callback for me.

Here's the code I am using:

~function(doc, $) {
    var select = $('select');

    // http://www.w3/TR/dom/#mutation-observers
    var observer = new WebKitMutationObserver(function(mutations) {
        alert(mutations.length + " mutations happened");
    });

    observer.observe(select, {
        // monitor descendant elements – changing `selected` attr on options
        subtree: true,
        attributes: true
    });

    // this triggers Observer's reaction, but doesn't update select box UI
    select.setAttribute('value', 'whee'); 
    // this updates select box UI, but doesn't trigger mutation observer's callback
    select.value = "whee";
    // this also updates the UI, but doesn't trigger mutation observer's callback
    select.getElementsByTagName('option')[0].selected = true;
    //
    // neither does manual selecting of options trigger mutation observer unfortunately :(

    button.addEventListener('click', function(e) {
        e.preventDefault();
        // my goal is to react to this change here 
        select.value = Math.random() > .5 ? "whee" : "whoa";
    }, false);

}(document, function(selector) { return document.querySelector(selector); });​

And here's this code in action http://jsfiddle/gryzzly/wqHn5/

I would like to react to changes to attributes (selected on <option> or value on <select>), any suggestion on why observer doesn't react is more than wele!

I am testing this in Chrome 18.0.1025.168 on Mac OS X. Production code would of course also have a moz prefix for the constructor and unprefixed version too, this is testing code.

UPD.

Tested the code in Firefox Nightly too and it behaves the same way as in Chrome, as well as in Chrome Canary. I have filled the bug for both browsers:

• https://bugzilla.mozilla/show_bug.cgi?id=757077
• https://code.google./p/chromium/issues/detail?id=128991

Please ment and vote for these bugs if you also find this problem annoying.

• javascript
• forms
• mutation-observers

Share Improve this question Follow edited May 21, 2012 at 16:29 Misha Reyzlin asked May 2, 2012 at 10:22 Misha ReyzlinMisha Reyzlin 13.9k44 gold badges5656 silver badges6464 bronze badges 6

• Don't think I'd want to rely on an experimental implementation of an unfinished spec. – Tim Down Commented May 2, 2012 at 10:28
• 1 Seems to be another manifestation of a related WebKit-rooted bug reported against Chromium: code.google./p/chromium/issues/detail?id=103551 – Alexander Pavlov Commented May 2, 2012 at 10:28
• 2 @TimDown who said I am relying on anything? :-) I am experimenting myself! – Misha Reyzlin Commented May 2, 2012 at 10:42
• perhaps I should report a bug on chrome bug tracker. – Misha Reyzlin Commented May 5, 2012 at 22:37
• Done: code.google./p/chromium/issues/detail?id=128991, also filling one for Firefox, as Firefox Nightly has exactly the same behaviour – Misha Reyzlin Commented May 21, 2012 at 16:15

 |  Show 1 more ment

1 Answer 1

Sorted by: Reset to default 5

@gryzzly, I've updated the Chromium bug with a detailed response: http://code.google./p/chromium/issues/detail?id=128991#c4

Mutation Observers are limited to observing the DOM serialized state. If you'd like to know if Mutation Observers can observe something, just do take a look at what innerHTML outputs for the element. If you can see the change in state reflected in changes to the markup which that produces, then Mutation Observers should be able to hear about it.

TL;DR: this is working as intended; to observe changes to IDL attributes like HTMLSelectElement.value, input events like onclick or onchange are probably your best bet.

本文标签：