[Webkit-unassigned] [Bug 47630] reversion bubble in WebViews
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Nov 4 12:56:25 PDT 2010
https://bugs.webkit.org/show_bug.cgi?id=47630
mitz at webkit.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #4 from mitz at webkit.org 2010-11-04 12:56:25 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > (From update of attachment 72904 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=72904&action=review
> >
> > Generally good, but enough comments to warrant a second round.
>
> Thanks for the review. I will make change as you suggest except two places that I have replied to your comment below.
>
> >
> > > WebCore/ChangeLog:18
> > > + 1. On Mac OS X, the result of spell checking is partly determined by past user usage. We can't
> > > + realiably generating test cases until we can disable user custom data during spell checking.
> >
> > Is there a way to set up the environment for DumpRenderTree such that it won’t be affected by user data?
>
> An SPI has been recently added to AppKit to disable user data. I suggest we hook up DumpRenderTree with said SPI in another patch.
Good idea.
> However, to make the automated test fast, we still need to be able to fake the delay.
I think that is also doable in the long term (as a separate change to WebCore and DumpRenderTree).
>
>
> > > WebCore/editing/CorrectionPanelInfo.h:58
> > > +enum CorrectionWasRejectedOrNot { CorrectionWasNotRejected, CorrectionWasRejected };
> >
> > I wonder if “Accepted” would be better than “Not Rejected”.
>
> The reason for this more confusing naming is due to the three different ways with which the correction panel can be dismissed.
> 1. Reject: when user press ESC key or click on the cross button on the panel.
> 2. Ignore: when user continues typing.
> 3. Accept: when user types whitespace or punctuation mark.
> This argument is used to distinguish case 1 from case 2 and 3, hence the name. Maybe I should use a enum type with three values, even though the handling of two of those values would be the same. That would make explicit the concept I just described. Thought?
I think it’s fine as-is.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list