Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@syranide, can you rebase? Based on @sebmarkbage adding that tag, I guess he's ready for this.

@zpao Will do, tomorrow.

@zpao Rebased. However!

scrollTop and scrollLeft does not have associated attributes #2140 (are there other property-only names we support?), I'm not 100% sure why they're exposed. I could add a HAS_NO_ATTRIBUTE flag to take care of it, but what is the expected behavior? Set them to null or leave them as-is?

Sorry, what's wrong with DOMAttributeNames as it is now?

@spicyj Nothing, I had missed that it's automatically filled with lower-cased names. :)

"Kind of waiting" for #2202

@zpao Apart from breaking (the already broken) scrollLeft and scrollTop (#2202) and triggering broken select-behavior (#2241) this PR should be good to go. But we probably want to wait for #2241 as a test otherwise fails.

document.body.innerHTML = '<form enctype="multipart/form-data">';
document.body.firstChild.removeAttribute('enctype');
console.log(document.body.firstChild.enctype);
> "application/x-www-form-urlencoded" 

Correctly restores the property value in all browsers I have my hands on, as you would expect.

#2202 merged. Waiting for #2241 (or similar) to prevent test error, unless you want to go ahead without that test (it's testing that selected values remain for an uncontrolled select when toggling multiple, which is half-broken right now anyway but passing the test).

Accepted but only once the dependency is resolved.

Dependency landed, I'll rebase and retest this PR.

We're the worst at merging… This is still passing all tests in a real browser and Phantom, but it's failing with jest, which is a bit of a bummer. It's actually an issue with the outdated jsdom we have in jest (which I'm going to fix... jestjs/jest#221). In the mean time we might have to xit those tests and add TODO comments.

@zpao This is on me actually, I got the go-ahead for merging my accepted ones some time (too long) ago after rebasing and testing... it's just been one thing after another on my end. But I'm trying to get some time over to go through my accepted PRs and get them rebased/tested soon.

@sebmarkbage @zpao I've verified that there aren't any other properties that should have MUST_DELETE_PROPERTY with a script that iterates through all elements supported by React and all configured properties (found #3000).

I've changed it to always set boolean properties to false instead of removeAttribute, this also neatly avoids the select.multiple-bug. However, I have left MUST_DELETE_PROPERTY on the affected properties even though it does nothing right now (but may in the future, like MUST_USE_PROPERTY).

There's an unsolvable edge-case for now; button.value will never lose the attribute due to sharing configuration with input.value, but it will still work as intended. But this is a minor nitpick considering we currently have significantly worse flaws without this PR.

So unless there's any red flags for you guys, this should be OK to merge from my POV.

EDIT: (jest) JSDOM was failing my new prop/attr tests, I commented out the affected rows in hopes that JSDOM will correct it in the future (or if we drop JSDOM). Ok? Or should I just remove the affected tests, they have some value they way they are now at least...

ping (no rush)

PS. I'm not quite sure why travis is failing this PR because of existing lint errors but not others?

Ping. I fixed the lint issue and I feel confident that everything is in order and that only the above mentioned caveats apply (which are far better than the current caveats), also note the issue with JSDOM tests.

Ok, I wrote a jsfiddle to help identify attributes that might warrant manual investigation. I ran it on chrome, next step is to run it on other browsers. Fiddle is located here: http://jsfiddle.net/gLd3hfrn/

On chrome, it flagged: radiogroup mediaGroup httpEquiv icon. The most interesting of which is httpEquiv (it didn't appear to work using attributes, though I'm not sure if chrome would honor the change if it were set using properties, so maybe it doesn't matter). Anyway, fwiw.

cc @syranide

Looks like http-equiv works fine if you spell it as http-equiv not html-equiv.

Ah, ok, that's good :). http comes right after html in the list of attributes, plays tricks on your mind.

Again really sorry for dragging my feet on this. Personally I'm mostly concerned about input controls and the various mutations of them (e.g. toggling multiple on select doesn't update value in some browsers when specifically removing the attribute (I think), etc) and them visually responding as they should (video/audio attributes/properties?). Also, this PR was initially intended to fix progress which previously wouldn't work as it required the absence of the attribute to correctly reset.

Simple test: http://jsfiddle.net/670u7ure/8/

However as you can see <progress /> still doesn't work properly because it should set value as an attribute, but it conflicts with <input> which requires it to be set as a property. We can hack around it by ignoring the property-flag if the node isn't <input>, <select>, etc, but that's really really ugly. A better alternative that's short of per-element-whitelist is to have a per-element-override, so value would be attribute by default but would be overridden to be a property for <input>, not sure about the perf implications of this. Anyway, this bug is already present so it's not a show-stopper, but it's worth figuring out.

@jimfb Do you feel like the transition from properties to attributes is safe from your tests?

Unrelated; Also, I noticed that React has acquired some weird behavior (in master) where it doesn't set value, checked, etc as attributes on first creation when rendering client-side, but if you render to a string and render on-top of that it behaves as "expected".

Unrelated 2; https://github.com/facebook/react/blob/master/src/renderers/dom/shared/DOMPropertyOperations.js#L176 that seems broken, NS-attributes don't obey by the property flags correctly.

@syranide updated the pull request.

PS. Another thing to consider, we could get rid of MUST_USE_PROPERTY too and leave it up to the wrappers to manage these properties instead. It would simplify the shared logic in DOMPropertyOperations.

Yes, we can move the .value logic to the wrappers. I wanted to make it use attributes at the low level anyway as part of a fix for #4618.

@spicyj Make that change first, then remove MUST_USE_PROPERTY from this PR and merge? Or how do we proceed?

Ping

I don't think they need to be intertwined. Will leave merging this to @jimfb since he's already done most of the testing.

Ok, I ran a whole suite of tests on a wide variety of browsers (firefox, chrome, ie, edge, safari, etc). I also cherrypicked this over to my devserver and ran through the whole react test flow. I think we've done our due diligence here. Worst case, we revert/fix, but I think the risk is low. Let's do this.

Totally missed that this landed, that's awesome @jimfb 👍

This PR introduces this bug: #6219

I discussed my solution in that thread a little bit and offered a small fix: #6228

The fix is aimed to preserve current behavior as much as possible without breaking anything.

We could leave it at that, but it might be better to reconsider current implementation in general. Current else-if chain responsible for setting/removing attributes/properties doesn't look straightforward.

@everdimension Just by looking at it I'm not entirely sure why that code is to blame or why yours fixes it, or why it worked before but not now (if that is the actual source of the problem)...

But the actual problem I assume should be related to the one described in #6119. Namely that value is considered a special-case now because of inputs but the same logic incorrectly applies to the value attribute for all tags. The solution is to un-special-case value either by moving the special logic to the input-wrapper or alternatively some form of per-element config. EDIT: But it still doesn't make sense to me... it should work anyway.

Oh now it makes sense to me, yeah, #6221 is the correct way to fix this. But I'm not sure why it worked before but not now still, that logic is the same, unless there are unrelated changes elsewhere that are the cause of this (I know selects/options have been updated).

@syranide did you meant #6228 ?

Oh my bad, #6119 is the one I meant I think. It removes the concept of these special properties so it no longer affects DOMPropertyOperations.