I was not able to reproduce this bug. 

In the Mozilla browser on my N800, pressing a directional button on the d-pad
causes scrolling a small amount in that direction. Holding it causes it to
continue scrolling (much like Opera).

I am also not having problems with finger or stylus scrolling being
unresponsive.

it's absolutely an unrelated bug, and if you don't provide precise steps with a
specific web page, or if you mention it in any unrelated bug, the bug
containing the comment will be marked invalid. I do not have time for bugs that
lose focus or are so vague that they collect other unrelated bugs.

Note: I expect that any bug you or anyone else files in this product has
precise steps to reproduce. Consider this comment a manifesto. Note that I'm
sorry if I've hijacked your bug, it's the first bug which wasn't specific
enough and this rant was going to happen in the first such bug.

1. use
https://bugs.maemo.org/enter_bug.cgi?product=N800&component=Browser%20(Mozilla%20Engine)&format=guided
for filing bugs
2. if you aren't a developer and can't be bothered with including steps to
reproduce, then you didn't read the announcement, we can't be bothered by your
bugs, so please don't waste our time. feel free to pay someone to write a
proper bug report.
For reference, I intend to use the same policy with people who are paid and
write poor bug reports, so please don't think I'm being particularly harsh to
volunteers. Note that mozilla.org gets good bug reports from volunteers (or
rather mozilla.org engineers fix good bug reports from volunteers, and other
bugs just rot).
2. Steps to reproduce are not optional. If I use about:blank as my testpage and
I press the arrow keys then I will *never* see the virtual keyboard, which
means that you have failed to explain to me what I should do.
3. The url field is not optional. I don't care if you think it happens on every
single page imaginable, all I'm asking for is *one* page where it happens.
4. Please indicate which locale you're using. When I file bug reports, I
include it, when I read bug reports, I use the locale to find the relevant code
based on error messages.
5. If you get an error message, please please please don't typo transcribing
the error. That makes life much harder. You're spending the time to write a bug
report, please spend the extra few moments it takes to get the spelling
correct.
6. If you use anything in a non standard setting, please mention it. That means
that if you've changed the virtual keyboard to pop up (or not) when you press
the select key, or if you've changed the virtual keyboard to include or not
include a space when it completes a word, please mention it.
7. please write expected results for each individual step, not just overall.
It's very important that I can figure out what's happening and if you want any
attention to be spent on a bug you have to make your bug *better* than its
competition. We have dozens of poor bugs internally, and our managers will want
us to spend our time on those bugs, so unless your bugs clearly show a problem
we'll instead spend our time marking those other bugs.
8. If you're using a network connection, please specify it. That means if
you're using Bluetooth, you should indicate that, if you're using WiFi, it'd be
nice if you specify if it's open, WEP, or WPA.
9. Please don't include side notes of any kind. Bugzilla is for specific bugs,
we don't need praise (and aren't expecting it), and we don't need random
comments. We need relevant details about specific problems.
10. Please be sure to indicate whether you have flash, JavaScript, or any other
interesting add-ons enabled or disabled.
11. You should probably indicate whether you're using full screen, have the
address field visible, and have the find toolbar visible.
12. please include the MicroB browser user-agent, that's reachable from about:
- which also happens to let you reach about:config and some other useful bits.
Note that the version field here in Bugzilla only lets you specify the system
version, not the application version, and I do expect that we will have
multiple versions as time goes by. I am not going to guess which version you
have (or had) installed. (If you want to include the debian package versions
for microb packages, you can do that instead, it's not recommended. If however
you think that some random package is causing interaction issues, then feel
free to attach some sort of package/version listing to your bug.)

Anyway. I'll look at this bug in a week, if it has specific steps (including at
least a URL).

It's OK and even encouraged for you to try multiple states, if a bug happens in
both full screen and windowed mode, or happens with and without javascript
enabled, mention it. preferably when you first file the bug, but it's OK if you
come back once and note a bunch of variations which don't influence things.

Obviously it's better if you find variations which do influence things.

darkstalker: thanks for looking.
Lastly, I know it's strange, but please don't say "Mozilla browser" the
codename is "microb", it's a public codename, you can use it freely. "Mozilla"
has various meanings and classically refers to Mozilla Application Suite (AKA
SeaMonkey). If you want to say "Mozilla Engine", you can. Note that there are a
number of browsers that can run on the N800, MiniMo, MicroB, Firefox,
Mozilla... I'm sorry about the overly long name, that's a pickle between
mozilla.org not wanting brand dilution (rightfully so, especially given that
the browser you're testing has major changes that are not in standard Mozilla
builds) and management deciding that they absolutely had to include the words
"Mozilla" and "maemo" in the name.

I also see this bug.  When I goto garage.maemo.org, wait for the page to load
and then try to scroll and the keyboard pops up.  This happens often on many
pages I have visited.

I'm also seeing the EXACT same bug as well.
My N800 was reflashed today to a pristine state with the newest
"It-has-Skype-now" firmware and the new browser was the first thing I installed
and started using.
Had this problem right from the start.

My experiences are after a reflash as well. Haven't seen anything like this...
but perhaps it's because I don't find myself using the d-pad much.

This works for me to reproduce the bug, at all times:

1) I have an external BT keyboard up and enabled
2) Select 'Tableteer' from bookmarks
3) Page shows up
4) Press 'down' on D-Pad
5) Virtual keyboard pops up.

I don't know if 1) is essential but this is how I'm currently set up.

I do not have a Bluetooth keyboard, but following your steps to reproduce,
minus step one, worked. It does indeed popup the keyboard. However it appears
that it only triggers the virtual keyboard on the first d-pad press after a new
browser window is opened. If you use the same browser window, the d-pad will
not popup the virtual keyboard whatsoever.

(In reply to comment #0)
> Whenever I press a direction button (and release) on the D-Pad in the new
> browser, it raises the virtual keyboard.  This is horrible and renders the
> D-Pad useless for scrolling.
> 
> As a side-note, I really like the way of using the D-Pad in Opera, with short
> presses jumping between links, and long presses scrolling the page. it would be
> great if this came back.
> 
> Finally, and possibly should be raised a separate bug, but I also find
> finger/stylus scrolling to be slow and unresponsive.
> 

I have noticed the same behavior, but have this to add.  It only pops up the
keyboard if there is a text entry field on the page being viewed.  If there is,
it immediately goes to the input field and pops the keyboard.  If there is no
input field, the scrolling seems to work as before.

hrm, didn't notice darkstalker marked this as assigned. I was going to unassign
this.

assuming you guys have finally settled on a bug report.

note that about:blank would not match the original description or summary but
does match what i expected. this is a known issue. I was hoping to rewrite the
navigation engine to enable special maintenance of this mode.

I think I've decided how I want to deal with it. and we've found the right
buggy spot. The logic error is that we were sending all keyups to a virtual
keyboard handler instead of only hardware select keyups.

Also notice that in the case I described I had a BT keyboard connected, so in
that case a virtual keyboard shouldn't have been launched for any reason.

yeah, thanks, that actually was a critical hint. now we'll just see how many
people don't find the bug with its new summary.

i believe this is fixed internally. I'll try to find out the process for
pushing an updated build tomorrow (Friday). I have no idea how long the process
is.

it turns out that this bug was not fixed, an attempt at hot potato was made. We
still know where to fix it. I'm hoping to get it fixed *now*.

This is now fixed and you can get the updated version with application manager.