Closed Bug 552914 Opened 10 years ago Closed 10 years ago

nsEditor::mFlags is never modified by SetFlags()

Categories

(Core :: Editor, defect, minor)

defect
Not set
minor

Tracking

()

RESOLVED FIXED
mozilla1.9.3a5

People

(Reporter: masayuki, Assigned: masayuki)

References

Details

Attachments

(1 file, 2 obsolete files)

Attached patch Patch v1.0 (obsolete) — Splinter Review
nsEditor::mFlags is set only when nsEditor::Init() is called.

nsPlaintextEditor::SetFlags() and nsHTMLEditor::SetFlags() don't call nsEditor::SetFlags(), so, nsEditor::mFlags are not modified forever.

I guess that this makes a problem after type attribute or readonly attribute of <input> element is modified and some code path which refer nsEditor::mFlags run. However, I'm not sure there are actual problems.

My patch removes nsEditor::mFlags. It's not needed. And the code should check the flags via GetFlags() method.

My patch also removes a special code for unix password editor in ForceCompositionEnd() which has never needed right now because we support ime-mode CSS property. So, even if the editor is password field, nsIWidget::ResetInputState() should be called at that time.
Attachment #433027 - Flags: review?(peterv)
Comment on attachment 433027 [details] [diff] [review]
Patch v1.0

smaug, can you review this? I requested to perterv, but there are no replies...
Attachment #433027 - Flags: review?(Olli.Pettay)
Comment on attachment 433027 [details] [diff] [review]
Patch v1.0


>+
>+void
>+nsEditor::OnFlagsChanged()
>+{
>   // Changing the flags can change whether spellchecking is on, so re-sync it
>   SyncRealTimeSpell();
>-  return NS_OK;
> }
I don't understand this method. Nothing seems to call it ever.


> 
> NS_IMETHODIMP
> nsEditor::GetIsDocumentEditable(PRBool *aIsDocumentEditable)
> {
>   NS_ENSURE_ARG_POINTER(aIsDocumentEditable);
>   nsCOMPtr<nsIDOMDocument> doc;
>   GetDocument(getter_AddRefs(doc));
>@@ -2177,21 +2187,16 @@ nsEditor::ForceCompositionEnd()
> // flag for Unix.
> // We should use nsILookAndFeel to resolve this
> 
> #if defined(XP_MAC) || defined(XP_MACOSX) || defined(XP_WIN) || defined(XP_OS2)
>   if(! mInIMEMode)
>     return NS_OK;
> #endif
> 
>-#ifdef XP_UNIX
>-  if(mFlags & nsIPlaintextEditor::eEditorPasswordMask)
>-	return NS_OK;
>-#endif
So you are, at least in theory, changing the behavior here.
Have you tested password fields with IME?


I think I would do this in different way.
Really start use nsEditor::mFlags always, and remove mFlags from nsTextEditRules.
nsTextEditRules can always access nsEditor::mFlags when needed.

Or is there some reason to not use nsEditor::mFlags, but nsTextEditRules::mFlags?
Attachment #433027 - Flags: review?(Olli.Pettay) → review-
Attached patch Patch v2.0 (obsolete) — Splinter Review
> >-#ifdef XP_UNIX
> >-  if(mFlags & nsIPlaintextEditor::eEditorPasswordMask)
> >-	return NS_OK;
> >-#endif
> So you are, at least in theory, changing the behavior here.
> Have you tested password fields with IME?

yeah, but I removed the change from the patch. I'll post the patch in separated bug.

> I think I would do this in different way.
> Really start use nsEditor::mFlags always, and remove mFlags from
> nsTextEditRules.

I agree.

And I found a bug:

>  nsTextEditRules::DidInsertBreak(nsISelection *aSelection, nsresult aResult)
>  {
>    // we only need to execute the stuff below if we are a plaintext editor.
>    // html editors have a different mechanism for putting in mozBR's
>    // (because there are a bunch more places you have to worry about it in html) 
> -  if (!nsIPlaintextEditor::eEditorPlaintextMask & mFlags) return NS_OK;
> +  if (!IsPlaintextEditor()) {
> +    return NS_OK;
> +  }

The condition is always false, but the comment doesn't expect so, of course. I replaced all flag checking to the new accessor methods for suppressing the mistake.
Attachment #433027 - Attachment is obsolete: true
Attachment #435856 - Flags: review?(Olli.Pettay)
Attachment #433027 - Flags: review?(peterv)
Comment on attachment 435856 [details] [diff] [review]
Patch v2.0


>+  PRBool IsAsyncUpdate() const
>+  {
>+    return (mFlags & nsIPlaintextEditor::eEditorUseAsyncUpdatesMask) != 0;
>+  }
Perhaps this could be called
PRBool UseAsyncUpdate() const

>+  PRBool IsNoCSS() const
>+  {
>+    return (mFlags & nsIPlaintextEditor::eEditorNoCSSMask) != 0;
>+  }
Maybe just
PRBool NoCSS() const

>+  PRBool IsDontEchoPassword() const
>+  {
>+    return (mFlags & nsIPlaintextEditor::eEditorDontEchoPassword) != 0;
>+  }
Maybe just 
PRBool DontEchoPassword() const
>--- a/editor/libeditor/base/nsEditorEventListener.cpp
>+++ b/editor/libeditor/base/nsEditorEventListener.cpp
>@@ -175,40 +175,30 @@ nsEditorEventListener::KeyPress(nsIDOMEv
> 
>   nsCOMPtr<nsIDOMKeyEvent>keyEvent = do_QueryInterface(aKeyEvent);
>   if (!keyEvent) 
>   {
>     //non-key event passed to keypress.  bad things.
>     return NS_OK;
>   }
> 
>-  // we should check a flag here to see if we should be using built-in key bindings
>-  // mEditor->GetFlags(&flags);
>-  // if (flags & ...)
>-
>   PRUint32 keyCode;
>   keyEvent->GetKeyCode(&keyCode);
> 
>   // if we are readonly or disabled, then do nothing.
>-  PRUint32 flags;
>-  if (NS_SUCCEEDED(mEditor->GetFlags(&flags)))
>+  nsEditor* editor = static_cast<nsEditor*>(mEditor);
I think you could make nsEditorListener::mEditor to be
type nsEditor. Currently it is nsIEditor. That way you wouldn't need the static_cast.
Though, it is possible that you'd need a static_cast then elsewhere. But try and see
what leads to easiest-to-read code.

>    nsCOMPtr<nsIEditorIMESupport> imeEditor = do_QueryInterface(mEditor, &result);
If mEditor was nsEditor, this QI wouldn't be needed.


>+  PRBool IsDontEchoPassword() const
>+  {
>+    return mEditor ? mEditor->IsDontEchoPassword() : PR_FALSE;
>+  }
DontEchoPassword()?
Attachment #435856 - Flags: review?(Olli.Pettay) → review+
Attached patch Patch v3.0Splinter Review
> I think you could make nsEditorListener::mEditor to be
> type nsEditor. Currently it is nsIEditor. That way you wouldn't need the
> static_cast.
> Though, it is possible that you'd need a static_cast then elsewhere. But try
> and see
> what leads to easiest-to-read code.

O.K. But I'll post the patch in another new bug.
Attachment #435856 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/97aec61ae55f

I'll file a bug for the previous comment.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Flags: in-testsuite+
Depends on: 581576
You need to log in before you can comment on or make changes to this bug.