I think all we need to do this is to make BuildScrollFrame no longer set the primary frame on the node. There are only two callsites: ConstructFrameFromItemInternal (which was working around this anyway; said workaround can be removed) and InitializeSelectFrame (which hands the frame out to ultimately ConstructFrameFromItemInternal, which last was setting the correct primary frame anyway and triggering the assertion).

Comment on attachment 419149 [details] [diff] [review] Fix Hmm. This might not be good enough due to letter frames. Will do some more testing.

Yep. Asserts all over the place with letter frames. Will fix, and make sure to run the layout/reftests/first-letter in a debug build before posting the next version.

Pushed http://hg.mozilla.org/mozilla-central/rev/ab3e23cefcce

What kind of situation would lead to an area element getting a frame?

> What kind of situation would lead to an area element getting a frame? Before this patch, or after? After, any time the <area> is used in an imagemap for an <img>. We set the primary frame of the <area> to the nsImageFrame (that's the nasty hack documented all over the frame constructor that you've run into before). Before this patch, the same as above plus if someone explicitly gave non-"none" display to the <area> it could get a frame via the normal frame-construction codepath...

(In reply to comment #7) > Before this patch, the same as above plus if someone explicitly gave non-"none" > display to the <area> it could get a frame via the normal frame-construction > codepath... Ah, okay, this was what I was asking.