Recomputing the placeholder visibility does not require the placeholder div
itself to be present, as the only information required for that is the current
value of the text control which is present either way. This patch fixes
nsTextEditorState::ValueWasChanged and nsTextEditorState::UpdatePlaceholderVisibility
to that effect.
But the real fix is in nsTextEditorState::UpdatePlaceholderText, where after
setting the placeholder text on the anonymous div, we redo the placeholder
visibility computation. Since this function can be called from
HTMLTextAreaElement::CreatePlaceholderNode during frame construction, the
GetValue function may return the wrong value since the editor has not properly
been set up yet, resulting in this bug. And this function call is useless
anyway, because changing the placeholder text does not really affect the
result of the visibility computation, so there is no need to do this work
in the first place.
Recomputing the placeholder visibility does not require the placeholder div
itself to be present, as the only information required for that is the current
value of the text control which is present either way. This patch fixes
nsTextEditorState::ValueWasChanged and nsTextEditorState::UpdatePlaceholderVisibility
to that effect.
But the real fix is in nsTextEditorState::UpdatePlaceholderText, where after
setting the placeholder text on the anonymous div, we redo the placeholder
visibility computation. Since this function can be called from
HTMLTextAreaElement::CreatePlaceholderNode during frame construction, the
GetValue function may return the wrong value since the editor has not properly
been set up yet, resulting in this bug. And this function call is useless
anyway, because changing the placeholder text does not really affect the
result of the visibility computation, so there is no need to do this work
in the first place.
If nsTextEditorState::SetValue is allowed to rebuild the editor DOM even when
the new value is the same as the old value, then during PrepareEditor we can
remove the content that's the current target of the event triggering the
PrepareEditor, which prevents important code from running such as the code that
focuses the text input. Normally this isn't a problem but
nsTextEditorState::SetValue's code for getting the current value is broken
for password controls when !mEditorInitialized. So we remove that broken code
path.
We have to make sure that the password text, if any, is set on the edit-rules
during their initialization so the regular path for getting the current
value returns the right thing.
--HG--
extra : rebase_source : 81a01a957b4b1e0cf868505a1b23c9110a2f4b3a
