1303629 - Element Attributes Rearranged

Status: RESOLVED WORKSFORME

(Core :: DOM: HTML Parser, defect, P3)

Description

[John A. Bilicki III]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160725105554

Steps to reproduce:

I type
<input class="a" type="text" />
in the textarea or it loads from the server/DB.


Actual results:

Either the browser renders it (forcing attributes in it's preferred fashion) or I after I manually fix the attribute order to be alphabetical I run either:
new DOMParser().parseFromString(s,'application/xml');
or
new XMLSerializer().serializeToString(s);
The attributes are rearranged.


Expected results:

The element attributes should NEVER be rearranged by the rendering engine for any reason! This obstructs the anticipated code by web authors and creates extreme discouragement of using any Gecko based browser.

This seems to apply to the id and type attributes specially though there may be others.

I have determined that there is no way to fix this other than manually grabbing the XML/HTML out of a textarea and fixing it AFTER using serializeToString and AGAIN having to waste resources at the server. This creates ANOTHER issue of having to create an option to enable/disable attribute sorting as some webmasters may want different attribute ordering.

Comment 1

[Tooru Fujisawa [:arai]]

can you provide a standalone testcase?

Comment 2

[John A. Bilicki III]

Attachment: gecko_bug_1303629_testcase_1.xhtml

Will alert string from serialized XML.

Comment 3

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Hi John,

I have tested this issue on the latest Firefox (49.0) release and latest Nightly (52.0a1) build. The "input" elements from the pop-up should be displayed in the same order like in the source code?
For testing this I have compared the "input" elements from the source code with the "input" elements from the displayed pop-up. Here are the results: 

On latest Nightly (52.0a1) build and latest Firefox (49.0) release:
The "input" from the source code: 
<input autocomplete="username" id="target_xml" type="text" value="" xmlns="http://www.w3.org/1999/xhtml" />
The "input" from the pop-up"
<input autocomplete="username" id="target_xml" value="" xmlns="http://www.w3.org/1999/xhtml" type="text" />

On Firefox (47.0) release:
The "input" from the source code looks like this: 
<input autocomplete="username" id="target_xml" type="text" value="" xmlns="http://www.w3.org/1999/xhtml" />
The "input" from the pop-up looks like this:
<input type="text" autocomplete="username" id="target_xml" value="" xmlns="http://www.w3.org/1999/xhtml" />

Comment 4

[Liviu Cirdei]

Removing "testcase-wanted" keyword as the testcase was provided in comment 2.

Comment 5

[John A. Bilicki III]

Tested Firefox 48~52.

48: bug still exists.
49+: bug changes but not fixed.

It seems in Firefox 49+ that the type attribute is now forcibly made the last attribute even though the test case has two attributes after the type attribute: value and xmlns.

The correct behavior is to NOT rearrange the attributes. I'm not sure why someone felt the need to waste time to program the attributes to be rearranged. It's a waste of time, code, bandwidth for development on Gecko and it's a waste of time for web developers.

Comment 6

[Henri Sivonen (:hsivonen)]

(In reply to John A. Bilicki III from comment #5)
> The correct behavior is to NOT rearrange the attributes.

Requiring attributes to be ordered is a fairly recent idea arising out of WebKit-ism.

> I'm not sure why
> someone felt the need to waste time to program the attributes to be
> rearranged.

Reasonable reasons not to preserve order include:
 1) Storing the attributes in a hash table. (This would explain the behavior of Microsoft's browsers.)
 2) Using different storage for attributes of qualitatively different kinds. (The Gecko case.)

Aryeh, do we already have a bug on file for getting rid of the mapped attribute bucket? If not, I guess this bug could be it.

Comment 7

[Andrew Overholt [:overholt]]

Bug 842367 is related here.

Comment 8

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I don't know of a bug.  All else being equal, we certainly should preserve attribute order, because otherwise there's no way for browsers to be interoperable.  I don't know how valuable the mapped attribute thing is or how hard it would be to remove, though, so it might outweigh the lack of interop given that Microsoft doesn't order attributes anyway.

Comment 9

[(no longer active)]

Looks like the issue in comment 0 is fixed in Nightly now?

Comment 10

[(no longer active)]

Resolving as works for me now. Please reopen if the problem with the attached test case can be reproduced again.