forcedotcom/aura

SecureMutationObserver breaking attribute name restriction

Closed this issue · 0 comments

I made a simple Mutator.cmp

<aura:component implements="flexipage:availableForAllPageTypes" access="global">
    <aura:handler name="init" value="{! this }" action="{! c.onInit }" />
    <aura:handler name="render" value="{! this }" action="{! c.onRender }" />

    {!v.body}
</aura:component>

and its corresponding MutatorController.js

({
    onInit: function(cmp, event, helper) {
        console.log('onInit');
        helper.myElement = document.createElement('div');
        helper.myMutationObserver = new MutationObserver(function() {
            console.log('attribute changed');
            }).observe(helper.myElement, {
                attributes: true
            });
        },
    
    onRender: function(cmp, event, helper) {
        console.log('onRender');
        helper.myElement.setAttribute('a', '.');
    }
})

I expected the call to helper.myElement.setAttribute('a', '.') in onRender to callback the MutationObserver and log 'attribute changed'. It did not.

However, if I run the same code natively on Chrome, MS Edge, or Firefox using this jsfiddle, the callback does happen, and I see

onInit
onRender
attribute changed

in my browser console log.

I can make my Lightning code work if I change

helper.myElement.setAttribute('a', '.');

to

helper.myElement.setAttribute('data-a', '.');

I'm guessing that Lightning is restricting user attribute names to data- prefix. This seems overly prescriptive, and breaks user DOM code that runs natively on major browsers. It also seems to not be in the spirit of User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them in the DOM (for DOM processors), and styling them according to CSS (for CSS processors), but not inferring any meaning from them.