Status

defect
RESOLVED WONTFIX
18 years ago
7 months ago

People

(Reporter: mpgritti, Assigned: blizzard)

Tracking

Trunk
x86
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

18 years ago
When I show a gtk context menu on right button mouse click and then I close it
choosing an item on the menu or clicking on the page, the focus seem to remain
on the link.
This is reproducable with galeon and any other application based on gtkmozembed,
it's very bad for galeon because it breaks the focus handling when opening new
tabs from contexts.

Updated

18 years ago
Blocks: 98995

Comment 1

17 years ago
Reporter, can you please elaborate on this?

Your description of the bug was not very clear.
Reporter

Comment 2

17 years ago
Sorry.
The only part I'm still able to reproduce atm is this:

1 Open a page in galeon
2 Use the context menu to open in a new window or tab
No status message is displayed when moving over links. This means that the
link_message callback is no more fired. When I click on the page all works fine
again.

To make this reproducable in TestGtkEmbed I should add a way to display a
context menu. Would this help ?
I'll also go through galeon bugs. I'm sure I've seen similar problems but I cant
find them now :(

Comment 3

17 years ago
OK. I see what you mean.
(I had tabs open in background so the bug only manifested when I would open new
windows)

Steps to reproduce.
1. Start galeon
2. Right click on a link and open in a new window
3. Try moving your mouse over the links and nothing happens

confirming on linux trunk 2002032300
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

17 years ago
for reference, the galeon issue:

http://bugzilla.gnome.org/show_bug.cgi?id=61109

Comment 5

16 years ago
The GTK2 port seems to have introduced a simple bug based on the GTK1 comment:
   // connect to the toplevel focus out events for the child

The top level here appears to have meant the top level mozilla embed, not the 
top level window.  This patch fixes the result of this confusing comment.

Here's what happens in the current code:
* The top level window receives a focus in/out event and calls the 
RootFocusController->SetActive(PR_TRUE/FALSE) for each GtkMozEmbed in the 
current window.
* SetActive causes the last tab opened to grab the focus.
* TAB's at this point cause the focus to walk the focusable nodes of the last
opened tab, rather than the current tab's document.

The GTK1 embed only does a SetActive on the currently focused GtkMozEmbed's
Root focus controller and maintains focus in the currently focused document.

This patch replaces the GTK2 version's NS_ACTIVATE handling with the GTK1's 
version's.

Updated

16 years ago
Attachment #129639 - Flags: review?(blizzard)
Reporter

Comment 6

16 years ago
The patch seem to try to address the same problem of 210373
Assignee

Comment 7

16 years ago
This is programming by side effect.  There are already focus handlers for the
child widget, which are attached seperately.  The code in question is actually
set up to listen for focus events on the toplevel window.
Assignee

Updated

16 years ago
Attachment #129639 - Flags: review?(blizzard) → review-
QA Contact: pavlov → gtk-widget
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
Embedding: GTK Widget isn't a thing, closing.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.