Possible perf suggestion

[csuwildcat]

I wrote one of these that used the same methodology many years ago and found that object elements with no navigation context were much lighter on memory than iframes. It has been so long I am not sure if this is still the case, so take this suggestion with a grain of salt.

[developit]

Indeed! I would love to see some benchmarks on this, since the approach you suggested is what the much larger element-resize-detector uses.

[csuwildcat]

@developit ha, small world: the other repo cites my code/blog post as the basis for its approach

I was at Mozilla when I wrote the original thing, and I used the built in mem tools we had to observe the memory allocations to elements embedded with iframes vs objects in various scenarios. There was a pretty significant difference as I remember, but it was so long ago I can't remember the specific numbers.

[developit]

It seems reasonably drop-in in terms of a swap, just change iframe for object and set the type to text/html, right?

[NekR]

@developit need to test first if <object> works as expected on all mobile devices.

[NekR]

Just a very naive heap allocation comparison:

Adding 100 iframes:

Adding 100 objects:

[developit]

hmm. not sure what to make of that. Object seems slightly better?

[NekR]

@developit to me it seems the same (see initial heap is smaller for the second attempt). Just left it here to show that it eats a lot of memory in general with both iframe and object.

[tigt]

It's possibly an edge case, but I have had no end of trouble with UC Mini messing with <object> in ways it really shouldn't; it shows neither <object data="foo.jpg" type="image/jpeg"> nor its internal fallback content, for example.

[NekR]

@tigt sounds like one more reason to not use <object>.

[developit]

Indeed. I don't trust it quite as much on mobile where flash never really necessitated that it work years ago