Comment 1 Eero Tamminen (reporter) 2008-08-12 13:45:13 UTC

If I install "gdb" & debug symbols for libX11, libgdk-x11, libgtk-x11
and glib, attach gdb to "browserd" and set break point to "XRaiseWindow",
I can see that browserd calls that 3 times when it's asked to open
another new page.  This seems to happen as side-effect of calling
gtk_widget_show thrice (I assume for the top level window).

The widget show would seem to be transferred from the UI process
to the browser daemon process with by the Gtk socket/plug window
embedding thing.  Maybe this is the thing making it worse in
Diablo.

Comment 2 Eero Tamminen (reporter) 2008-08-12 13:47:24 UTC

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

Still happens with the 4.2008.30-2 upgrade

Comment 4 Eero Tamminen (reporter) 2008-08-12 17:13:37 UTC

Created an attachment (id=868) [details]
Gdb backtraces to the three XRaiseWindow calls from browserd

When attaching with Gdb to the Browser UI process, it says:
-----------------------------------
(gdb) break XRaiseWindow
Function "XRaiseWindow" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (XRaiseWindow) pending.
-----------------------------------

And opening new window doesn't trigger this breakpoint.
This seems a bit suspicious, but that's up to browser
developers to debug... :-)

Comment 5 Andre Klapper 2008-08-14 17:14:04 UTC

Thanks for the investigations, forwarded an internal ticket.

Hi,I've reproduced this "bug".In my opinion , internet tablet creen is
small,and taskbar is to short to set application above the floor( like windows
operation system),so applications are always set on top.This kind of design may
be a "notice",tell the users "hi, execution has been completed".

That's my personal opinion , as N810 user.

PS:I've try many other applications (e-mail.contacts.filemanager···)They happen
to cross the same situation.

Comment 7 Eero Tamminen (reporter) 2008-08-19 11:15:02 UTC

(In reply to comment #6)
> Hi,I've reproduced this "bug".In my opinion , internet tablet creen is
> small,and taskbar is to short to set application above the floor( like windows
> operation system),so applications are always set on top.

The problem described here isn't that new (browser) windows are topped when
they're created (opened for the first time).  The problem is that browser
tops its window several additional times *after* it has already opened/topped
it.


> PS:I've try many other applications (e-mail.contacts.filemanager···)
> They happen to cross the same situation.

If you have a test-case, please describe the exact steps (in separate
bug, the window rising is done by the application itself).

Sorry for my negligence.
As I know only brower can open multi windows.
Is it possible that brower is opened as a new application every time?

bugzilla is for bugs. not generic inquiries. as it happens, browsers do not
appreciate running more than once. they generally have a lot of state they like
to share among windows. technically you can create as many distinct browser
based applications and run each of them on your device, however any one
application will get only one distinct browser daemon process.

Comment 10 Eero Tamminen (reporter) 2008-08-19 19:27:53 UTC

Created an attachment (id=893) [details]
Gdb backtraces to XRaiseWindow calls from browser UI

Using gdbserver on device & gdb in Scratchbox with debug symbols
I was able to get backtraces also from the UI process.

It seems that if the UI takes too long to respond (while it's suspended
by Gdb), the daemon gets restarted which causes huge number of additional
XRaiseWindow calls in the UI as response to additional D-BUS calls:
#3  0x4148e374 in browser_controller_load_url (self=0xaf828, url=0xaf8b4 "",
    new_window=986432, from_frame=0, context=0x0, update_urlfiled=1,
    set_current=1, save_req=0) at browsercontroller.c:1469
#4  0x4148e790 in open_url_request (arguments=0x1, self=0xaf828,
    retval=0x1605c19, new_window=1, save_req=0) at browsercontroller.c:572
#5  0x4148ed70 in ossobrowser_rpc_callback_handler (interface=0xa3960 "",
    method=0x18f920 "open_new_window", arguments=0x179e90, data=0xaf828,
    retval=0xbecb40e0) at browsercontroller.c:663

(In reply to comment #9)
> bugzilla is for bugs. not generic inquiries. as it happens, browsers do not
> appreciate running more than once. they generally have a lot of state they like
> to share among windows. technically you can create as many distinct browser
> based applications and run each of them on your device, however any one
> application will get only one distinct browser daemon process.
Thanks,My idea is that everytime the browser was created the "browserd calls
that 3 times when it's asked to open another new page".

Comment 12 Ryan Abel 2008-10-15 15:30:01 UTC

This is becoming an increasingly infuriating issue for me, and not just with
the browser. Our limited CPU power means there's a lot of time to do other
things while waiting for applications to figure out what they're doing (say,
the browser loading a web page, or Modest taking its time opening an email),
unfortunately, they applications are rather insistent about staying on top
while they're accomplishing absolutely nothing, and this is made even worse
with our single-window window manager.

Basically, I want to see applications when I ask for them, not at any other
point, and especially not when the application thinks I want to see it.

So, would there be any way to disable self-topping at the xserver or window
manager level? Fixing this at the application level doesn't seem to be very
productive at the moment. . . .

Comment 13 Eero Tamminen (reporter) 2008-10-15 15:40:50 UTC

(In reply to comment #12)
> So, would there be any way to disable self-topping at the xserver
> or window manager level?

No, that would probably break everything.  X server or window manager don't
know whether user requested a window or not, only the application knows it (and
it could also use override redirect to tell that WM shouldn't touch the
window).


> Fixing this at the application level doesn't seem to be very productive at the moment. . . .

If there are other applications that have the same annoying issue of topping
themselves when user has put them into background, please file separate bugs
about them (and put me on CC).

What is the progress with thin in the Browser?

if we have progress, we'll list it. we're busy running around in circles.

bugzilla is not for polling. you should not ping people in bugs, otherwise (and
especially with our process) all bugs will have is hundreds of comments asking
for status updates.

Comment 16 Roope Rainisto 2008-11-24 20:40:36 UTC

I'd like to move this to the UI specifications...

Comment 17 Roope Rainisto 2008-11-24 20:43:37 UTC

OOPS. Not this bug, sorry. Moving back. (Where's the undo button when you need
one)

Ok, So you're runnig in circles.

I want to know if this BUG will be fixed for Frem.

This bug has so many votes because your device is soo slow, that any normal
user will want to do something else while the browser is starting (it takes up
to 10 seconds). 

On slow connections loading of a page takes time, and the user wants to do
something in the meanwhile. But (s)he is disturbed but the browser stealing
focus again (up to twice).

So, if you're 'running in circles' turn off the window stealing behavior.
Non-super-users won't notice that. They don't use tablet more than 2 weeks.

Comment 19 Andre Klapper 2009-02-16 15:32:04 UTC

(In reply to comment #18)
> I want to know if this BUG will be fixed for Frem.

"if we have progress, we'll list it." It's hard to misinterpret that sentence.
So *currently* there is no progress, and it's too early to say for final
Fremantle.

(In reply to comment #13)
> (In reply to comment #12)
> > So, would there be any way to disable self-topping at the xserver
> > or window manager level?
> 
> No, that would probably break everything.  X server or window manager don't

Havoc Pennington says (in private IRC): "on the maemo bug, they should be
ignoring XRaiseWindow() in the WM. Even metacity does that."

I hope that helps.

I made a small .so with my own XRaiseWindow() containing nothing but a debug
printf and a return, and LD_PRELOAD it into browserd (confirmed by
/proc/pid/maps and the printfs appearing in terminal).

Based on this, the browser calls XRaiseWindow() 3 times for every new window.
This matches empirical observations by myself and other users in the amount of
times focus is stolen.

However, just ignoring XRaiseWindow is no cure, the browser still manages to
force itself to front through some other way.

Still valid for 4.1.3 (5.2008.43-7) release

Comment 23 Andre Klapper 2009-04-28 12:43:43 UTC

24 votes. :-/   Now I wonder whether this still happens in Fremantle.

Comment 24 Quim Gil 2009-04-28 13:24:49 UTC

(In reply to comment #23)
> 24 votes. :-/   Now I wonder whether this still happens in Fremantle.

Mmm it seems like it still happens, but you need to be really fast changing
windows to trigger it with your first browser instance. Launching e.g. the 6th
browser window seems to be easier to trigger it.

So perhaps the cause is still there, but the annoyance might be less in regular
use.

What if there's a problem with resolving DNS?

Browser will wait a while (then you can switch to other window) so you'll get
another focus steal when DNS will be resolved and page starts loading.

Comment 26 Quim Gil 2009-04-28 13:44:30 UTC

(In reply to comment #25)
> What if there's a problem with resolving DNS?

I can check... if there is any URL to test.

/me has no idea :)
Anyway my idea is to test what happens when there's a delay (few sec) between
opening a browser window from a clicked link and showing the page contents.
What if during that time user will switches to other window. If the browser
will steal focus after that, the bug is not fixed.

Comment 28 Quim Gil 2009-04-28 13:57:17 UTC

Testing with this week's build, you need to jump out of the browser before it
actually finishes drawing it's window (before you get the browser toolbar at
the bottom). Once this is drawn then it seems that you can safely go away while
the page starts loading the content. It won't call the browser back.

So, part of this bug is not 'fixed' :)

If drawing takes more than 2 sec. this is still an issue here.

(In reply to comment #24)
> Mmm it seems like it still happens, but you need to be really fast changing
> windows to trigger it with your first browser instance. Launching e.g. the 6th
> browser window seems to be easier to trigger it.
> 
> So perhaps the cause is still there, but the annoyance might be less in regular
> use.

For me it was most annoying if I used the ad block plus plugin for microb.
Using this plugin (and a filter subscription like 'easy list') the browser
needs initial much more time to start and you can the effect of this bug very
clear. For me this bug was the reason to uninstall the ad block plus plugin.

Comment 31 Andre Klapper 2009-06-15 21:09:30 UTC

Okay, summarizing the current state in Fremantle:

(comment #24)
> Mmm it seems like it still happens, but you need to be really fast changing
> windows to trigger it with your first browser instance. Launching e.g. the 6th
> browser window seems to be easier to trigger it.
> So perhaps the cause is still there, but the annoyance might be less in 
> regular use.

(comment #28)
> Testing with this week's build, you need to jump out of the browser before it
> actually finishes drawing it's window (before you get the browser toolbar at
> the bottom). Once this is drawn then it seems that you can safely go away 
> while the page starts loading the content. It won't call the browser back.

(comment #29)
> So, part of this bug is not 'fixed' :)
> If drawing takes more than 2 sec. this is still an issue here.

As this is way harder to trigger I consider closing this as "WORKSFORME in
Fremantle" (and WONTFIX for Diablo as Diablo will only receive critical updates
if at all. The Mer project aims to provide a Fremantle port for N8x0 machines).

Comment 32 Quim Gil 2009-09-14 08:00:55 UTC

Let's do that. I don't think this is a problem perceived by Maemo 5 users.

Comment 33 Ryan Abel 2009-10-20 08:53:23 UTC

Not getting it nearly as often as in Diablo, but definitely seeing it.

Comment 34 Tim Samoff 2009-10-21 21:09:56 UTC

This is definitely still an issue in Fremantle. Sometimes the focus is "stolen"
2-3 times as a web pages loads (i.e., I open a link and navigate to another
app, the browser comes back for some reason, but is not completely loaded so I
navigate away again and then it comes back, etc.). Pretty easy to reproduce.

Comment 35 Andre Klapper 2009-10-22 21:38:58 UTC

Can somebody please come up with an updated STEPS TO REPRODUCE description for
the Fremantle UI? Thanks in advance!

Comment 36 Ryan Abel 2009-10-22 21:46:58 UTC

(In reply to comment #35)
> Can somebody please come up with an updated STEPS TO REPRODUCE description for
> the Fremantle UI? Thanks in advance!
> 

Generally speaking the steps haven't changed:

1. Open the browser.
2. Begin loading a page.
3. Open the dashboard and switch to another application.

It seems to happen more often when the device is under a heavier load.

Comment 37 Tim Samoff 2009-10-22 21:48:59 UTC

1. Open browser
2. Type URL (anywhere)
3. Before web page loads, open another application (anything)

Expected outcome:
Webpage loads and completes in background while other app has focus.

Actual outcome:
When webpage is finished loading, the browser regains focus and the user is
navigated away from the current app, back to the browser.

I am *unable* to reproduce this bug using the provided step by step
descriptions.

I did the following:
1. I opened the browser
2. I typed www.youtube.com + [enter]
3. While the website was loading I started the contacts and the calendars
application and was playing around with them a little bit.

Actual outcome:
Browser doesn't tops itself. I also can't remember that this happens since I am
using a N900.

Do you have an always working way to make this comprehensible always for
everybody? Maybe it would help to describe exactly which website the browser is
loading and to document every single fingertip to the touch screen?

if people are using GPRS or WiFi they should specify that ...

I use a N800, with wifi connetion. Here are some more details of the bug.

If the browser is already on, there is no problem. Also, it's not when the page
finishes loading that the focus is changed. Here are my steps to reproduce it:

1_ With the browser closed, click on a link in any program (except for the
browser, of course!). For example, click on the link to the page of this bug in
the beginning of this e-mail. The browser will be started, and focus will move
to it, naturally.
2_ Immediately move back to the e-mail window, as when you open a link and want
to come back to continue reading the message. In little time focus will move
back again to the browser, where it might be still loading the page, displaying
only a blank page.
3_ If you try another time to move back to the e-mail window, it should change
focus for the third time. This is the last time it happens, if you get back
again to the e-mail window the browser won't top itself again, not even when
the page finishes loading.

So, it's just when you open up the browser by clicking on a link in some other
program that this happens. If the browser is already open there is no problem,
both if you type the link directly into the browser, or click on a link in
other programs, e.g. the e-mail reader.

My last message describes a situation where the bug can be seen, but there are
in fact other cases. For example, the description in the very first message:
open up some application, and the open up the browser. After browser window
shows up, move to the application you opened previously. The focus will then
move back to the browser one or two times, while it loads its default start
page.

Sometimes the undesireble focus changing does happen if you, for example,
select a link in your browser bookmarks and move to another previously opened
application. The focus will move quickly back to the browser, even before the
page finishes loading. But in my experience the bug is more erratic in these
cases than when opening links from other application when the browser is
closed.

I'll make a new bug for maemo5. This one is for Diablo on N8x0.

Comment 43 Andre Klapper 2010-03-11 15:20:33 UTC

Nokia currently has no plans to fix this for Maemo4, hence closing as WONTFIX
to reflect the reality.
The Maemo5 bug for this issue is bug 5792 (Thanks jukey!)