Text field lazy initialization
I just landed a set of patches on mozilla-central which makes the initialization of the editor for text fields (input type="text" and input type="password" in HTML terms) lazy. What we used to do was to initialize the editor component for text fields as soon as we created frames for those elements. This was not ideal, because users don't usually use all of those fields on web pages (think about the "search" text fields you see on every website nowadays, for example.) It also made Gecko significantly slow for pages which included a lot of those elements.
What these patches do is that they defer the initialization of the editor component (which actually allows you to type into the fields, copy and paste stuff, undo/redo your edits, etc.) until when the user is most likely to use it (for example, when the control is focused, or receives keyboard input.)
The work to make this happen was a lot more than I originally anticipated. It uncovered a number of other problems, which I've already fixed or I'm going to. It also proved to be a long journey as I saw different changes in the tree break my work a lot. Overall, those problems should have made the patches more robust, but I thought I'd post this change here so that nightly testers can have it in their minds in order to track any possible regressions. These changes will be in tomorrow's nightly build.
Update: Actually, I spoke too soon. The changes caused a problem and I had to back them out. Hopefully the problem is resolved soon and I'll re-land the patches.
Update 2: The code has landed and has been stabilized on trunk now.
Comments
That sounds like a good
That sounds like a good improvement - and probably also explains why I've seen some interesting strangeness with getting focus to a an editing area in some recent builds. If I see it again, I know it wasn't me alone and I'll look for a bug or file one ;-)
Re: That sounds like a good
Well, I had to back out the patch yesterday, so unless you've used a build from the short period while the patches were in the tree, you shouldn't have seen any relevant issues. But anyway, filing bugs is always a good idea!
Congrats Ehsan, and thanks
Congrats Ehsan, and thanks for all the care you took in landing this work without breaking accessibility; it is sincerely appreciated.
Should there be any
Should there be any noticeable difference? Will there be a small delay when clicking on a text input now?
Should there be any
Hopefully, the only difference would be that some web pages would load faster! The amount of work to initialize the editor for a single text field is not that much, and it's a lot less than what humans can perceive.
Pingback
[...] Text field lazy initialization | Ehsan Akhgari ehsanakhgari.org/blog/2010-04-06/text-field-lazy-initialization – view page – cached I just landed a set of patches on mozilla-central which makes the initialization of the editor for text fields (input type="text" and input type="password" in HTML terms) lazy. What we used to do was to initialize the editor component for text fields as soon as we created frames for those elements. This was not ideal, because users don't usually use all of those fields on web pages (think... Read moreI just landed a set of patches on mozilla-central which makes the initialization of the editor for text fields (input type="text" and input type="password" in HTML terms) lazy. What we used to do was to initialize the editor component for text fields as soon as we created frames for those elements. This was not ideal, because users don't usually use all of those fields on web pages (think about the "search" text fields you see on every website nowadays, for example.) It also made Gecko significantly slow for pages which included a lot of those elements. View page New on ehsanakhgari.org [...]