[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