Fix tiny bugs of setAttr()/updateStyle()

[kfule]

Fixed a few tiny bugs in attributes and style properties updates.

Description

• removes key === "is" from setAttr() to fix 2799 Custom elements: built-in element extensions lose their is attribute #2799 (comment)
  • Also, for code consistency, the key === "is" is removed from removeAttr() as well.
• swaps set and removal order in updateAttrs()/updateStyle() to prevent accidental removal for newly setting values
• removes cssText property access as Bypass css text #2811 .

Motivation and Context

I found a strange behavior in the process of #2985, although it rarely happens (#2985 (comment)). And there seems to be a similar trivial issue in updateAttrs() (flems.)
This could be solved by simply swapping the order of set and removal probably without creating new bugs and perf issues.

Also, I am not very familiar with custom elements, but it seemed to me that the #2799 issue could be solved by simply removing key === "is" from setAttr().

How Has This Been Tested?

• npm run test including test code fix for custom elements
  • Sorry, but I did not make any changes to domMock because the changes seemed more complicated than the bug fix code.
• I have also confirmed that the issues are not reproduced in flems above using fixed bundle.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My change requires a documentation update, and I've opened a pull request to update it already:
• I have read https://mithril.js.org/contributing.html.

[kfule]

I am a little sorry for my frequent pull requests these days.😢
I did not plan for this pull request, but it seemed like an easy bug to fix...

I think these are bugs that almost no one cares about, so I won't hurry you to review or merge it.

[dead-claudia]

You still need to fix the diff algorithm (this will have negative perf impact) to compare is values for non-custom element vnodes.

• If the is attribute disappears, the element needs replaced so it's no longer a custom element.
• If the is attribute is newly added, the element needs replaced so it's now a custom element.
• If the is attribute changes, the backing custom element needs to change to be that new type.

In all three cases, it's simpler and more predictable to just remove and re-create.

[kfule]

@dead-claudia
Thanks for the comment. As you commented, this PR is going to have unpredictable behavior for users (even if it is straightforward javascript behavior). I will take some time to think about it some more.

I think I will close this PR for now. There is no hurry at all to fix the other bugs in this PR.

[dead-claudia]

@dead-claudia

Thanks for the comment. As you commented, this PR is going to have unpredictable behavior for users (even if it is straightforward javascript behavior). I will take some time to think about it some more.

I think I will close this PR for now. There is no hurry at all to fix the other bugs in this PR.

@kfule The current behavior isn't any more "predictable". What I suggested was really just a one line fix plus some more (pretty straightforward) tests. Sorry if this wasn't clear.

[kfule]

@dead-claudia
I have reopened this PR. I would like to request your review.

The following changes related to attr/style have been added to the previous PR. Both are small changes, I think.

• remove key === "is" from removeAttr() as well (mainly for code consistency with setAttr())
• remove cssText property access (cf. Bypass css text #2811)

I have not added any tests, but I would like to add tests if needed.

---

Also, I thought about your comment about "is" being "unpredictable".
When the value of "is" is set/changed/deleted, it would be better to delete the element and re-create it as you commented.
For instance, it would look fine to change the call updateElement() as follows:

default: {
	if ((old.attrs && old.attrs.is) == (vnode.attrs && vnode.attrs.is)) {
		updateElement(old, vnode, hooks, ns)
	} else {
		removeNode(parent, old)
		createElement(parent, vnode, hooks, ns, nextSibling)
	}
}

However, I personally would be more careful about adding code to this area because of the performance impact (about a several percent drop).
The "is" attribute has not yet been implemented in safari and does not seem to be planned to be implemented. I don't think I will be using “is” for a while yet.

[dead-claudia]

However, I personally would be more careful about adding code to this area because of the performance impact (about a several percent drop).

@kfule Try adding a bits field to the vnode that has the lowest bit set (var IS_CUSTOMIED_BUILTIN = 1 << 0) if it's a customized built-in. There's slight memory tradeoff (10 -> 11 fields, or 52 -> 56 bytes in V8), but it won't impact much else. Be sure to add it as the first field so it's most likely to reside on the same cache page as the tag.

A bit test from a field allocated inline in the object is very cheap. It's only a few bottlenecking instructions (4-6 at most) in the fast path plus an extra immediate generation + memory store (that won't bottleneck), so it should avoid significant perf deviations.

You'll also have to do a hasOwn.call(vnode.attrs, "is") check in m, which will cause some extra perf degradation, but doing it in m pretty much ensures it'll be fetching from cache, and this will save a lot of time. Plus, it's a pure existence check, so engines can skip some of the property value access work, and the use of hasOwn avoids the prototype walk (and attempt to set up inline caches on the result).