Would changing that line with svgContainer[key] bypass the warning? Can you try editing the final bundle?

Clever! Indeed, it does not appear as a warning if I change the line in my bundle from

(ri = ri || document.createElement('div')), (ri.innerHTML = '<svg>' + r + '</svg>');

to

(ri = ri || document.createElement('div')), (ri['innerHTML'] = '<svg>' + r + '</svg>');

I think changing the access to svgContainer["innerHTML"] in Vue's source won't work in the long run though because minifiers will rewrite that expression to a.innerHTML anyway.

Is this warning blocking for extensions or not? @blimmer

According to my own experience of maintaining a Firefox add-on, the warning will not block the submission process. There are many add-ons relying on jQuery or other 3rd party libs, you can clarify the situation in your comments to reviewers and this should be fine. I don't think it's necessary to handle this in Vue's source code.

I haven't submitted the extension yet, so I'm not 100% sure. Similar to what @Justineo was saying, I think it won't block me for submitting, though it does flag the extension to send it through the review process which slows things down.

Vue is certainly not alone in this, I've also filed an issue with lodash for another warning: lodash/lodash#4985

The use of innerHTML is required in Vue, not only in this case but also core features like VDOM patching. I don't think it makes sense to bypass the code check when the code itself needs further review. We shouldn't pretend it doesn't exist.

The VDOM patching link above is reading from innerHTML, not assigning it. The warning is only generated when assigning innerHTML. With Vue's runtime version, the linked code is the only place Vue is assigning innerHTML (from what I can tell from the lint output).

I don't think this is a huge deal necessarily, but it would be nice not to trigger Mozilla review since we don't support IE11.