This is still happening OS2008.

Ok, I've checked that correctly.
Is steals focus when the brtowser starts, typipcal for every app on the device.
But there's second focus steal after 'Updating' when it starts loading homepage
(or other page).
If this is intentional, I'm hope I never met the person who designed it...

Recently I also discovered why Nokia prefers Firefox; it's as slow as Maemo
QA's.

Hey! Be nice. Vitriol and bile won't get this bug fixed any faster.

Yup. I know. But it might stab them in the mind. Me and other people here who
bought this crap lost their patience. Nokia just get pre-alpha testers for
free; phew, even they pay for being their testers. Shame that it doesn't
respect them.

Confirming.
Browser steals focus a second time a few seconds after starting it. Apparently
when the page starts loading.


Łukasz, people responsible for hiring testers do not read this bug. People who
are responsible for fixing this bug might. I'd appreciate it if you could be
respectful or at least not abusive towards them.

Thank You! At least conmfirmed.
I hope it won't take long to take care of this.

I do not intend to abuse a person (except those who should confirm this bug 2
months ago). I indend to offend Comp..ergh..any called Nokia. The testers I
mentioned in last comment, are the people who paid money for this
good-idea-poorly-done tablet like me. I'm feeling cheated by Nokia, like many
others.

it will take long to take care of this, for a number of reasons:
1. there's no pending release
2. i have no idea what function is the culprit.

fwiw i was reading your bugmails as you wrote them, berating us really isn't
helpful. we're also aware of the problem.

if you'd like to be helpful you could research which X11/gtk functions
technically can trigger requests for focus.

Thank you again.

That's what I wanted to hear 2 months ago (well, maybe not exactly this ;) )

Comment 9 Ryan Abel 2008-06-12 10:54:13 UTC

This seems to have gotten worse in Diablo (3.2008.22-8). The browser will steal
focus as much as three times during a page load.

It seems that it's a general OS fault.

You can notice similar behavior when You start eg. Mail client.

It seems that the app steals the focue when the app windows content is being
rendered.

Comment 11 Andre Klapper 2008-08-01 22:20:20 UTC

> The browser will steal focus as much as three times during a page load.

I can confirm this.

Comment 12 Ryan Abel 2008-08-04 08:06:50 UTC

(In reply to comment #10)
> You can notice similar behavior when You start eg. Mail client.
>

Not the same issue, all operating systems that I know of give a newly opened
application focus. The issue here is the browser stealing focus during page
loading while it's in the background.

As I meant, whe have 3 issues here, 2 of them are System specific and should be
separated
1) Newly open window steals focus - Poorly designed UI
2) Window steals the focus when it's content is rendered eg. Menus, toolbars
etc. - one can see that in Email app, if you change the window before it(email
app) shows it's content, you'll get the focus stolen. - This may be the same
reason as 2nd steal in Firefox.
3) Browser steals focus when the page starts rendering - The crucial issue here

Comment 14 Andre Klapper 2008-08-08 17:20:14 UTC

*** Bug 3507 has been marked as a duplicate of this bug. ***

Comment 15 Andre Klapper 2008-08-08 17:34:42 UTC

(In reply to comment #12)
> The issue here is the browser stealing focus during page
> loading while it's in the background.

Sounds explcitily like a browser issue then, hence reassigning.

I wouldn't be so sure, the 2nd point is the same annoying BUG as the 3rd in the
browser, however it may be systemwide.

Comment 17 Eero Tamminen 2008-08-11 11:24:51 UTC

I'm assuming this is about *keyboard* focus.

(In reply to comment #13)
> As I meant, whe have 3 issues here, 2 of them are System specific and
> should be separated
> 1) Newly open window steals focus - Poorly designed UI

This is how it works by default in all operation systems.  New windows
open mostly as response to user action so this is sane default (when you
open an application, you expect to be able to input to its window without
needing to click it first).  For new things not to get focus, they should
specify that they aren't focusable at all I think (for example banners
in the device work like this).

I think this part is bogus.


> 2) Window steals the focus when it's content is rendered eg. Menus,

Menus are new windows and always(?) opened as a response to user action.
So this seems bogus also.


> toolbars etc. - one can see that in Email app, if you change the window
> before it(email app) shows it's content, you'll get the focus stolen.

Redraws by default don't get focus, application needs to specifically
do it.  I.e. this is applications/use-case specific and needs separate
bug for each application.

Please file E-mail bugs against E-mail, not Browser.


> 3) Browser steals focus when the page starts rendering - The crucial
> issue here 

Some of the www-pages have JavaScript that focuses a field on the page
which as a result focuses also the page/window.  This is issue with
the www-pages (I think e.g. google page does that), and you should
complain to the authority maintaining these www-pages, not here.
Timeless, could you elaborate this a bit?


I'm sure there are valid use-cases where the applications focus their
pages when they shouldn't but this bug is a bit too vague. I think it
should be invalidated and properly written bug reports filed instead.
If you're interested in how to file effective bug reports, this page
can help:
  http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

I think this bug could be used for finding the relevant use-cases from
browser (e.g. what URL etc) and initial checking of whether it's really
an application or www-site issue before filing the real bugs and
invalidating this one...  Alternatively this could be turned to
a meta-bug that depends from the real bug reports.



(In reply to comment #9)
> This seems to have gotten worse in Diablo (3.2008.22-8). The browser
> will steal focus as much as three times during a page load.

Browser engine moving to a separate process (to get better improved
speed and reliability) and being embedded to the browser UI in Diablo
might explain this, but please give exact steps on how to reproduce this
(exact steps, from which URL and from what Browser steals the focus
three times etc), preferably in a separate bug.

Just now I was trying to zoom in in the rss reader and it didn't do anything, I
couldn't even open the rss reader menu. Switched to the browser window and it
was at 180%.
Back to the rss window and, again, neither the zoom buttons nor the menu didn't
work. Had to close the browser window to be able to zoom the rss reader.
I can also say that sometimes with the browser opened, while on an xterm window
the enter key of the on-screen keyboard does nothing (and it's impossible to
access the shotcut keys of the xterm) until I close all browser windows.

Eero, if I open a link in a new window, then in the tasks menu I select the
previous window (note that the tasks menu already lists the new window), I
don't expect that the new window will steal the focus after I explicitly
decided that I don't want it to.
Also, I don't expect a random browser window to steal focus when it feels like
it while I'm reading another window (that I explicitly selected).
At least it didn't happen under chinook.
BTW, I think this is a different issue, but it has been closed as a duplicate
of this bug.

Comment 20 Eero Tamminen 2008-08-11 12:45:28 UTC

(In reply to comment #18)
> Just now I was trying to zoom in in the rss reader

From the zoom keys on top of the device I assume...

> and it didn't do anything, I couldn't even open the rss reader menu.
> Switched to the browser window and it was at 180%.
>
> Back to the rss window

I.e. you topped RSS window after topping Browser?
Window should by default get focus also when when it's topped.


> and, again, neither the zoom buttons nor the menu didn't
> work. Had to close the browser window to be able to zoom the rss reader.

Tapping RSS window didn't allow you to input key events to it?

If this is true, then this is not an issue with keyboard focus
(focus that can be changed between windows just by tapping a focusable
window (application) into which you want to get the keyboard focus),
but keyboard grab.

Keyboard and pointer grabs are "evil", only things that are
AFAIK supposed to use them in the device are:
* Popups which need to close when user taps outside them
  (menus, combobox popups etc)
* Keyboard shortcut bindings (configurable from the Bluetooth keyboard
  control panel applet)
and even in those grabs should be used with caution.


> I can also say that sometimes with the browser opened, while on an xterm
> window the enter key of the on-screen keyboard does nothing (and it's 
> impossible to access the shotcut keys of the xterm) until I close all
> browser windows.

What are XTerm shortcut keys?


(In reply to comment #19)
> Eero, if I open a link in a new window, then in the tasks menu I select the
> previous window (note that the tasks menu already lists the new window), I
> don't expect that the new window will steal the focus after I explicitly
> decided that I don't want it to.
>
> Also, I don't expect a random browser window to steal focus when it feels
> like it while I'm reading another window (that I explicitly selected).

Is this about keyboard focus (something you can change by tapping
the window you want to get key events) or grab, or window topping?


> At least it didn't happen under chinook.
> BTW, I think this is a different issue, but it has been closed as
> a duplicate of this bug.

You can re-open a bug with and explanation if it doesn't seem like
a duplicate.

>> 1) Newly open window steals focus - Poorly designed UI

>I think this part is bogus.

No it's not. The browser doesn't allow to open a page in a background
window/tab, so it's a poor UI. Also good Windows Managers allow to choose how
window focus should be controlled.

>> 2) Window steals the focus when it's content is rendered eg. Menus,

>Menus are new windows and always(?) opened as a response to user action.
>So this seems bogus also.

No it's not. Why do I need a reaction when the app opens it's UI and does not
wait for user reaction.  BY DEFAULT in all operating system, window doesn't
steal focus when it renders it UI buttons.

>> 3) Browser steals focus when the page starts rendering - The crucial
>> issue here 

>.Some of the www-pages have JavaScript that focuses a field on the page
>which as a result focuses also the page/window.  This is issue with
>the www-pages (I think e.g. google page does that), and you should
>complain to the authority maintaining these www-pages, not here.
>Timeless, could you elaborate this a bit?

Ther's no need for use cases. EVERY page steal focus when it starts to be
rendered.


It seems that Eero doesn't use Maemo OS, he could see that at the very first
start. I don't blame him. Only we, users, are so stupid to use that.

Comment 22 Ryan Abel 2008-08-11 17:56:51 UTC

(In reply to comment #21)
> It seems that Eero doesn't use Maemo OS, he could see that at the very first
> start. I don't blame him. Only we, users, are so stupid to use that.
> 

Now, now. We're ALL on the same side here, there's no need to get angry and
resort to attacks.

Anyway, I'm definitely of the opinion that this bug is valid. All the other
unrelated stuff aside, the browser is clearly stealing focus when it shouldn't
be (both from itself and other applications). One thing I do quite frequently
is begin loading the page, then switch to XChat (or something similar) to
continue chatting, and have the browser pull focus from there up to 3 times
(begin loading, switch to XChat, get switched back to browser, switch to XChat
again, get switched back to browser again, switch to XChat, then get switched
back to the browser again) during page loading.

This is definitely not the way it works with any of my desktop browsers, and
definitely not the way it should work in MicroB.

(In reply to comment #20)
> (In reply to comment #18)
> > Just now I was trying to zoom in in the rss reader
> 
> From the zoom keys on top of the device I assume...

Yes: I couldn't use the menu since it didn't work (next linr of my comment)

> 
> > and it didn't do anything, I couldn't even open the rss reader menu.
> > Switched to the browser window and it was at 180%.
> >
> > Back to the rss window
> 
> I.e. you topped RSS window after topping Browser?

Yes

> Window should by default get focus also when when it's topped.
> 
> 
> > and, again, neither the zoom buttons nor the menu didn't
> > work. Had to close the browser window to be able to zoom the rss reader.
> 
> Tapping RSS window didn't allow you to input key events to it?

As I said, the hardwarre zoom buttons weren't working (the events went to the
browser instead)

> 
> If this is true, then this is not an issue with keyboard focus
> (focus that can be changed between windows just by tapping a focusable
> window (application) into which you want to get the keyboard focus),
> but keyboard grab.
> 
> Keyboard and pointer grabs are "evil", only things that are
> AFAIK supposed to use them in the device are:
> * Popups which need to close when user taps outside them
>   (menus, combobox popups etc)
> * Keyboard shortcut bindings (configurable from the Bluetooth keyboard
>   control panel applet)
> and even in those grabs should be used with caution.
> 
> 
> > I can also say that sometimes with the browser opened, while on an xterm
> > window the enter key of the on-screen keyboard does nothing (and it's 
> > impossible to access the shotcut keys of the xterm) until I close all
> > browser windows.
> 
> What are XTerm shortcut keys?

those at the bottom of the xterm window. You can see those that don't fit by
tapping the triangle at right, but in this case the triangle didn't show
anything. Note also that I could type in the xterm window except the enter key. 


> (In reply to comment #19)
> > Eero, if I open a link in a new window, then in the tasks menu I select the
> > previous window (note that the tasks menu already lists the new window), I
> > don't expect that the new window will steal the focus after I explicitly
> > decided that I don't want it to.
> >
> > Also, I don't expect a random browser window to steal focus when it feels
> > like it while I'm reading another window (that I explicitly selected).
> 
> Is this about keyboard focus (something you can change by tapping
> the window you want to get key events) or grab, or window topping?

In this case is window topping.
It seem I'm experiencing all the bugs at once ;-)
Unfortunately I couldn't determine the steps to reproduce the bug(s), they seem
random to me.

Oh, I didn't tell but I have a n800, so no hardware keyboard.

Comment 25 Eero Tamminen 2008-08-12 13:47:24 UTC

(In reply to comment #22)
> > It seems that Eero doesn't use Maemo OS, he could see that at the very
> > first start. I don't blame him. Only we, users, are so stupid to use that.

I'm not related to browser development and I use browser less & differently
than device power-users so I haven't been disturbed by this issue myself.
It's a bit embarrasing, but because the bug report talked about focusing
(which has a very specific meaning in relation to window management which
is closer to my field), I had missed that this bug was about window topping.
Sorry about that.


> One thing I do quite frequently
> is begin loading the page, then switch to XChat (or something similar) to
> continue chatting, and have the browser pull focus from there up to 3 times
> (begin loading, switch to XChat, get switched back to browser, switch to XChat
> again, get switched back to browser again, switch to XChat, then get switched
> back to the browser again) during page loading.

Thanks, this is excellent use-case description, I filed a separate focused
bug with more exact use-case and correct terminology and mark this as
duplicate so that others coming across similar issue don't need to wade
through this one.

I put everybody on CC here there too (except dyearga whom Bugzilla didn't
recognize), but you need to re-apply votes.


The other issues mentioned here should be reported as separate bugs:
- Enhancement request for an option to open new pages on the background
  (I think against UI specs instead of Browser)
- Focus stealing (not topping like this bug) mentioned in comment 23,
  after a repeatable use-case is found


*** This bug has been marked as a duplicate of bug 3557 ***