323910 - Merge gklayout atom lists

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We currently have quite a few atom lists in gklayout, nsHTMLAtoms, nsXULAtoms, nsXBLAtoms, nsLayoutAtoms, etc. This leads to a fair amout of duplication of string data as well as differences in naming of the same value ("*" and "class" both have three different names in different classes).

The various lists also leaves some usecases without an obvious list to use. For example XMLEvents uses nsHTMLAtoms although it's not HTML specific in any way.

Patch comming up to merge all these lists into a single list, nsGkAtoms.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Patch to fix

This patch creates a single list, but makes the old code work by typedefing nsLayoutAtoms etc to nsGkAtoms. At a later point we should create a separate search-n-replace patch that changes all users to use nsGkAtoms directly.

I removed all duplicate atoms which meant that I had to rename a few atoms, like ::templateAtom into ::_template. However in most cases the duplicates had the same name across the different atom lists.

The content/xslt changes are slightly different then the changes to the other atom lists since transformiix standalone still needs its own atom lists. That's all #ifdef'ed though.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: With whitespace fixes

Forgot to run a last diff after I had done some whitespace fixes.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 208881 [details] [diff] [review]
With whitespace fixes

+		nsGkAtomList.h \
+		nsGkAtoms.h \

maybe nsGeckoAtoms would be more readable?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I went for something short, but I can't say I feel super strongly about it.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: This one's golden

I realized that the previous patch doesn't build when MOZ_XUL is undefined. The only difference is that this one won't create a library for content/xul/content/src when MOZ_XUL isn't defined

Comment 6

[Johnny Stenback (:jst)]

Comment on attachment 208898 [details] [diff] [review]
This one's golden

Yeah, golden :) r+sr=jst

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Checked in, saved just under 3k