[haiku-webkit-commits] Re: r262 - in webkit/trunk/WebKit/haiku: API WebCoreSupport

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: haiku-webkit-commits@xxxxxxxxxxxxx
  • Date: Tue, 02 Mar 2010 09:56:23 +0100

On 2010-03-02 at 02:21:45 [+0100], Ryan Leavengood <leavengood@xxxxxxxxx> 
> On Mon, Mar 1, 2010 at 7:30 PM,  <webkit@xxxxxxxxxxxxxxx> wrote:
> > Author: stippi
> >
> > Log:
> > * Only handle B_KEY_DOWN events in BWebPage. This makes repeat work 
> > properly.
> That's funny because when I was testing I had put a second if to check
> for B_KEY_DOWN (which logically would be equivalent to your &&) and it
> never got past the first if (so I removed it.) Though the fact that
> this works now may be related to your other changes in
> EditorClientHaiku.

Yes, of course.

> > * Don't implement the events in EditorClientHaiku, which don't work. On 
> > second
> >  thought, we could probably just do what BWebPage now does. Shouldn't 
> >  matter
> >  much in any case.
> Are you sure they don't work? They only apply to text controls, so for
> example you would not notice them unless you are inside a text area.
> For example I'm editing this email in Gmail (in Firefox in this case)
> and if I press page up, page down, the arrow keys, etc it applies to
> the text area, not to the whole page.

Yes. It's handled in EditorClientHaiku. See the separate method it uses for 
editable nodes.

> So while my change was wrong in always scrolling the page on key up, I
> don't think commenting out the stuff in editor client was correct
> either, since now you can never keyboard scroll inside text fields.
> Though I still need to test these changes.

Ah, I thought you wrote this because it doesn't work anymore.

> > These changes prevent the BWebPage keyboard handling to interfere with 
> > text
> > editing.
> Unless you beat me to it I'll take another look and investigate the
> editor client stuff more.

I already did. Unless you found something that doesn't work. :-)

Best regards,

Other related posts: