Investigate the performance of the DOMParser and see if there are any mitigations
Categories
(Firefox :: Translations, task, P3)
Tracking
()
People
(Reporter: gregtatum, Unassigned)
References
Details
The addon used innerHTML for setting the contents of a DOM element. In the TranslationsDocument, we are using a DOMParser. This is an order of magnitude slower mostly from having to create a full Document element for every node that gets translated. We should investigate if there is a better solution for this that is still secure.
|
Reporter | |
Comment 1•3 years ago
|
||
Since this is a general performance improvement, I'm going to move it from the Desktop MVP to the general backlog.
|
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 2•2 years ago
|
||
|
|
Reporter | |
Comment 3•2 years ago
|
||
https://share.firefox.dev/3Tx3GeI
I think this is a WONTFIX. The DOMParser seems much faster these days. I wish I had retained a profile from when I had filed this bug, but my memory of the timing was that it was mostly spent in creating the document object. I don't see that work now. The parseFragment code doesn't seem to be any faster now.
It is slower to use a parser, but doesn't seem as drastic as it used to be. This is probably an acceptable trade-off due to the safety of not using innerHTML.
Description
•