Closed Bug 261959 Opened 20 years ago Closed 17 years ago

column picker doesn't respond properly to mouseclicks (gtk1 builds)

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: bugzilla, Assigned: jag+mozilla)

References

Details

(Keywords: regression) 

coudln't find an open bug which describes this particular, but pls dup and/or
reassign as needed.

the column picker widget doesn't respond properly to mouseclicks.

recipe:

1. go to a window or dialog which contains a column picker, eg:

* bookmarks manager
* history manager or history sidebar
* mailnews 3pane window
* addressbook window

2. click and release the column picker widget to expand the menu.

3. move the pointer (hover without clicking, yet) to highlight the item you'd
like to select in the column menu.

4. click and release to actually select the menu item.

expected: a checkmark appears (or disappears if already selected) next to the
selected menu item, the menu goes away, and then corresponding item's column
appears (or disappears) in the tree.

actual results: the menu disappears, but the chosen column doesn't appear (or
disappear) --no change to the tree view occurs.

workarounds:

a. at sept (4) click and hold for at least 1-2 sec, then release sometimes
selects the menu item properly.

b. or, at step (3) use the arrow keys to select the menu item and at step (4)
use the Enter key to activate the menu selection.

tested with 2004092717-trunk (seamonkey) on linux fedora core 2, but this
problem was still evident in 2004091907-trunk. this used to work, so will narrow
down regression window...
Asa mentioned that he has seen this on Windows XP.
OS: Linux → All
this regressed over two months ago, some time btwn 2004071321-trunk and
2004071419-trunk.
Column picker works fine for me in all the places mentioned on Windows XP sp1. 
I do see this broken, between 2004-07-14-07 and 2004-07-14-19.

Note that when I click the menuitem the menu just goes away and if I then hover
over the column picker widget (but don't click), it gets the depressed
appearance it got when I clicked on it.

Based on that and the checkin window, this looks like a regression from
hierarchical :active.  At a guess, clicking the menuitem sends the columnpicker
widget active, which causes a reframe, which tears down the menu before the
click is registered...
In Bookmark Manager, clicking the + next to a bookmark folder will change it to
a - and "open" the bookmark folder icon, but nothing actually opens or changes
other than that.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040928
Firefox/0.10 (bangbang023)
That has nothing to do with this bug that I can see (for one thing, your build
is from 3-4 months before this bug first appeared).
Blocks: 262429
This bug still exists on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5)
Gecko/20041019.

I have just been looking at bug 253729 which appears to be a duplicate.
Suggested it is marked as such but haven't go permissions.

There are a couple of build ids, this one didn't work:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040729

whereas this one was meant to:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040726

Don't know if this helps.
*** Bug 253729 has been marked as a duplicate of this bug. ***
Is it just a matter of fixing styling here?
Flags: blocking1.8a5?
gonna have to wait till a6.
Flags: blocking1.8a5? → blocking1.8a5-
Flags: blocking1.8a6?
Even something as simple as changing the amount of padding seems to confuse the
picker in its current incarnation as a button plus a manually opened popup.
However I was able to turn the picker into a menubutton to resolve the issue.
Note that menubuttons open on mousedown; the old columnpicker opens on click.
See also possibly related/duplicate bug 276756. Note: from the comments &
related bugs this bug seems only to be appearing on Linux even though the OS on
the bug is set to all.
Blocks: 276756
Can we back out the change that caused this regression if we can't easily fix
it? This seems like a good one to try to get fixed for 1.8.
when using 2005010606-trunk gtk2 bits on linux fc2, I no longer see this
(double-checked in both modern and classic themes as well).

was this backed out, or fixed by a patch in another bug? either way, marking
w4m, but do reopen if it's still an issue in a recent trunk build.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
I'm still seeing this with a 2005-01-06-05 GTK1 build of SeaMonkey.  I can
confirm that the issue isn't there in a GTK2 build, and I can't find a way to
test it in Firefox.  Trunk thunderbird is too broken to test in, as far as I can
tell (the column picker gives an empty menu).

Reopening based on the GTK1 build being broken, though.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: column picker doesn't respond properly to mouseclicks → column picker doesn't respond properly to mouseclicks (gtk1 builds)
Flags: blocking1.8a6? → blocking1.8a6-
OS=all? Should this just be unix/linux?
Thanks. Maybe the title should be changed then?
*** Bug 281356 has been marked as a duplicate of this bug. ***
*** Bug 284239 has been marked as a duplicate of this bug. ***
*** Bug 257382 has been marked as a duplicate of this bug. ***
*** Bug 266233 has been marked as a duplicate of this bug. ***
This is most likely a regression from bug 65917. The checkin for that was inside
the window indicated in comment 2, and when i remove the :active part of
http://lxr.mozilla.org/seamonkey/source/themes/classic/global/win/tree.css#247
the picker works like it should. (the line now reads |treecolpicker:hover|.
Ofcourse it doesn't look like it should, but it works)

dbaron, bz: can you look into this, as author and reviewer of the patch in bug
65917?
This works for me now, I probably fixed it in bug 282359 or bug 279769.
No, not fixed. Using build 2005050405 (from ftp.mozilla.org, gtk1) i still can't
change the columns in the bookmark manager.
> This is most likely a regression from bug 65917.

Of course.  See comment 4.

I _have_ looked into this.  The basic problem is that the widget is insisting on
changing its styling significantly on :active, but matching :active doesn't
necessarily mean the _widget_ was clicked.  It could be any descendant of the
widget.  In particular, it could be a menuitem in a menu.

So I suspect the "right" solution is to move the :active styling to only the
part of the widget that we care about (the button) or to introduce a
non-hierarchical :-moz-activecontent or something and use it here.  Someone more
familiar with this widget than I should comment on the feasibility of the former...
(In reply to comment #25)
>No, not fixed. Using build 2005050405 (from ftp.mozilla.org, gtk1) i still can't
>change the columns in the bookmark manager.
Shame on me, I didn't look at the id of the build I downloaded today to
double-check with, but my columnpickerss worked fine.
(In reply to comment #26)
>So I suspect the "right" solution is to move the :active styling to only the
>part of the widget that we care about (the button)
The widget already is the button... the only way you could resolve that is to
move the menupopup into the treecols binding.
So the problem is that the menupopup is actually a child of the button?

Does the button have some sort of attribute or something set when the menupopup
is up?  That is, could we use something like:

  :not([open]):active

as the selector?
Not that I know of, as this is really a popup rather than a menu.
And changing it into a menu gives me some lovely crashes...
*** Bug 298486 has been marked as a duplicate of this bug. ***
Happens in Firefox 1.5RC3 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5) Page Info dialogs, all of its tabs. 
Not in Bookmarks Manager.
I got this bug in SeaMonkey 1.0 [ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060126 SeaMonkey/1.0] on two separate machines with Slackware GNU/Linux on board (ver. 9 and 10).
I've tested gtk1.tar.gz and gtk1-installer release.
I always have this bug with a seamonkey 1.0 - gtk 1 on sparc/Solaris 8.

I already saw this problem, in the past, with a Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8b2) Gecko/20050712.

It's *not* a pc problem, it's for all hardware and all os and it's a blocking problem for me because I can't to propose seamonkey to replace Mozilla suite :(
(In reply to comment #34)
> I always have this bug with a seamonkey 1.0 - gtk 1 on sparc/Solaris 8.
> 
> I already saw this problem, in the past, with a Mozilla/5.0 (X11; U; SunOS
> sun4u; en-US; rv:1.8b2) Gecko/20050712.
> 
> It's *not* a pc problem, it's for all hardware and all os and it's a blocking
> problem for me because I can't to propose seamonkey to replace Mozilla suite :(
> 

Yep -- on Solaris 8, we can't build Seamonkey 1.0 (or 1.0.1) with GTK 2, and when we build it with GTK 1, we have the column picker bug.
--
Jeff Wieland
Gtk1/xlib widget code has been removed on trunk and this bug doesn't seem
like a branch candidate.  I can't reproduce the bug in SeaMonkey and Firefox
trunk builds (gtk2).  Please reopen the bug if you can reproduce in a recent
trunk build.

-> WONTFIX
Status: REOPENED → RESOLVED
Closed: 20 years ago → 17 years ago
Resolution: --- → WONTFIX
it's a pity that this bug  won't be fixed any more; 

my created BugID was also closed :-(
https://bugzilla.mozilla.org/show_bug.cgi?id=377768

We want using all recent products (FF,Seam,TB) with GTK1 because they 
dont waste resources (lower memory used) and use also CDE as preferred desktop
(not gnome/gnome2) - but these all have this "little" bug !!!

Use MOZ1.7.13 anymore ?

-> Please FIX


Please first read existing comments before writing new ones. Comment 36 already describes why this bug was closed. GTK1 code doesn't exist on trunk anymore and this is not a security issue so it even won't be fixed for 1.8 branch.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.