Closed
Bug 163503
Opened 22 years ago
Closed 18 years ago
[gtk1] Using :hover and (or) :focus and (or) :active on select fields makes them almost unusable
Categories
(Core Graveyard :: GFX: Gtk, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: georgi, Unassigned)
References
Details
(Keywords: regression, testcase)
Attachments
(4 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020819
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020819
If on select form element are applied :hover and :focus pseudo class,
the drop down star acting not like standart dropdowns.
Reproducible: Always
Steps to Reproduce:
1. View the attached testcase
Reporter | ||
Comment 1•22 years ago
|
||
Comment 2•22 years ago
|
||
Confirming. John do you know anything about this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•22 years ago
|
||
Sounds a bit like bug 154670, but not the same.
Comment 4•22 years ago
|
||
all three testcases regressed at the same time (2002051621 - 2002051721, same as
bug 154670). the third testcase is (almost) bug 154670.
Comment 6•22 years ago
|
||
*** Bug 165376 has been marked as a duplicate of this bug. ***
Comment 7•22 years ago
|
||
*** Bug 173056 has been marked as a duplicate of this bug. ***
Comment 8•22 years ago
|
||
*** Bug 174982 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
Checkins in the window above:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2002-05-16+20%3A00&maxdate=2002-05-17+22%3A00&cvsroot=%2Fcvsroot
My first guess would be aaronl's changes (bug 130969), although it could also be
bryner's or hewitt's.
Comment 10•22 years ago
|
||
Here's what I see:
- If a dropdown is already open, it takes 2 clicks to open another dropdown
- If no dropdowns are open, it only takes 1 click
This part of the bug is realated to bug 66834.
For me, where :hover or :focus is on the select doesn't affect the behavior, so
I guess I'm not seeing this bug.
Comment 11•22 years ago
|
||
The example in http://www-xray.ast.cam.ac.uk/~jss/test-option.html shows the bug
well. The drop down box never opens unless you double click, and it doesn't open
reliably then (example from bug 173056). This is with Mozilla 1.2b (2002101612)
on Linux.
Comment 12•22 years ago
|
||
Jeremy, I only need 1 click to drop the box down in that example, at least in
win2k. Maybe it's a platform thing. I'm on the tip from last Wednesday October
16, 2002.
Reporter | ||
Comment 13•22 years ago
|
||
The bug is only seen in linux builds, that's why OS is set to Linux only
Comment 14•22 years ago
|
||
I don't know what the difference is between this bug and bug 154670. That bug
was caused by bug 126480 (hewitt)
Comment 15•22 years ago
|
||
Someone mentioned problems with :active as well (on mozilla-style).
Comment 16•22 years ago
|
||
*** Bug 177918 has been marked as a duplicate of this bug. ***
Comment 17•22 years ago
|
||
*** Bug 180900 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
*** Bug 181005 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.3beta
Comment 20•22 years ago
|
||
*** Bug 186404 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Summary: Using :hover and (or) :focus on select fields makes them almost unusable → Using :hover and (or) :focus and (or) :active on select fields makes them almost unusable
Comment 21•22 years ago
|
||
*** Bug 192066 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
*** Bug 195123 has been marked as a duplicate of this bug. ***
Comment 23•22 years ago
|
||
*** Bug 196208 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
*** Bug 211093 has been marked as a duplicate of this bug. ***
Comment 25•21 years ago
|
||
I found that this behavior is still present if the select is inside a table tr
that has a :hover style (I would guess that the :focus styles would behave
similarly as well), instead of the style being on the select element itself.
See the testcase.
Comment 26•21 years ago
|
||
*** Bug 224114 has been marked as a duplicate of this bug. ***
Comment 27•21 years ago
|
||
*** Bug 228054 has been marked as a duplicate of this bug. ***
Comment 28•21 years ago
|
||
The sample URL in dup bug 228054 shows that this doesn't need a table to occur.
URL: http://www.dmbr.ugent.be/~didier/moz16-hover_select_inoperable.html
Keywords: regression
Comment 29•21 years ago
|
||
In dup bug #228054, I reported that 1.4 worked perfectly OK ; reading this bug
#163503, I should have added I only considered the Red Hat RPM builds (RHL9 1.3
and Fedora Core 1 1.4.1). I just tested all mozilla.org builds since 1.4 (both
with and without gtk/xft), and they all show the same erroneous behaviour.
Tonight, I'll compile the source tarball with the FC1 1.4.1 buildconfig
parameters. If that does not provide a clue, I suppose the patches provided in
the RedHat SRPMs will provide a clue.
Comment 30•21 years ago
|
||
WRT comment #29 :
I recompiled the mozilla-source-1.6b.tar.bz2 (20031209) source tarball with the
RedHat/Fedora buildconfig parameters :
"--prefix=/usr --libdir=/usr/lib --enable-optimize=-O2 --disable-debug
--enable-pie --with-default-mozilla-five-home=/usr/lib/mozilla-1.4.1
--disable-strip-libs --disable-tests --enable-xinerama --enable-nspr-autoconf
--enable-extensions=default,irc --without-mng --enable-crypto --disable-xprint
--without-system-nspr --with-system-zlib --enable-default-toolkit=gtk2
--disable-freetype2 --enable-xft --mandir=/usr/share/man"
This fixes the issue.
IMHO, it could prove advantageous to compare mozilla.org's buildconfigs with
this one, as they all (both xft and non-xft) lead to the erroneous behaviour,
just like the one below (which I previously used) :
"--enable-calendar --with-system-zlib --enable-xft --enable-crypto
--enable-extensions=default,inspector,-irc --enable-xpctools --disable-tests
--disable-logging --enable-reorder --enable-strip --disable-debug
--enable-optimize=" -O2 -march=pentium3 -pipe" --enable-toolkit=gtk2
--enable-striplibs "
Comment 31•21 years ago
|
||
*** Bug 229886 has been marked as a duplicate of this bug. ***
Comment 32•21 years ago
|
||
I was recently hit by this bug in the "<select> inside a <tr> with a :hover"
case. I confirm that this bug is still present with the following releases:
* Mozilla 1.6 - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
* Firefox 0.8 - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207
Firefox/0.8
I also tested with these nightly and the bug is still present:
* Mozilla 1.7b - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040324
* Firefox 0.8+ - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b)
Gecko/20040324 Firefox/0.8.0+
I run under an old Mandrake Linux 8.1 (Glibc-2.2.4, XFree86-4.1.0), but this
also occurs with Firefox 0.8 under a recent Mandrake (where XFree86 is 4.3 I
think).
Comment 33•21 years ago
|
||
Bug 239084 looks like a dupe of this. I attached a testcase over there, I can
put it in here (or just look at that one).
I *only* see it in gtk1 builds. Using a gtk2 build, the problem is not
reproducable. Both testcases on this bug work right using Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.7b) Gecko/20040410 Firefox/0.8.0+ (which is in fact a
gtk2 build).
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040411 (gtk1) *does*
show the symptoms in both testcases. Mine is reduced pretty far, it uses
{text-decoration: underline} on a form element and gets the same behavior.
Comment 34•21 years ago
|
||
So.... if I change the restyle hint for background and color changes from
NS_STYLE_HINT_VISUAL to nsChangeHint_RepaintFrame the problem in the first
testcase disappears.
That's not a fix, of course (though I think we should go through and do it as
possible, since view sync ain't cheap), since other style changes _do_ require
the view sync. But apparently something
nsContainerFrame::SyncFrameViewProperties does just messes with the popup's
little mind. This is born out by comment 33 -- apparently something in the gtk1
widget impl is just unhappy about SyncFrameViewProperties and tears down the
popup....
Comment 35•21 years ago
|
||
*** Bug 239084 has been marked as a duplicate of this bug. ***
Comment 36•20 years ago
|
||
*** Bug 256477 has been marked as a duplicate of this bug. ***
Comment 37•20 years ago
|
||
this bug in mozilla 1.7.3 still persists...
Comment 38•20 years ago
|
||
Yes, we know.
Reassigning this to GFX widgetry, per comments....
Assignee: john → blizzard
Status: ASSIGNED → NEW
Component: Layout: Form Controls → GFX: Gtk
Keywords: helpwanted
Priority: P2 → --
QA Contact: tpreston → ian
Target Milestone: mozilla1.3beta → ---
Comment 39•20 years ago
|
||
*** Bug 258724 has been marked as a duplicate of this bug. ***
Comment 40•20 years ago
|
||
OK, resending my experience with that bug, since I filed it to a duplicate bug.
I'm using Select inside of a table, which is using hover:
Built firefox under Linux from source both gtk and gtk2.
gtk2 build - no problem at all
gtk build -the described behavior from previous posts
removing the hover from the stylesheet makes the select response as usual.
I'm using gtk 1.2.7 - quite old, I know. Don't know if this is gtk or firefox
related. I'd prefer firefox ;-) , don't wan't to upgrade gtk on all my machines,
and as the selection works without the hover, the error is likely to be in firefox.
Comment 41•20 years ago
|
||
the source was (of course) firefox-1.0, forgot to mention ...
Comment 42•20 years ago
|
||
*** Bug 275069 has been marked as a duplicate of this bug. ***
Comment 43•20 years ago
|
||
Comment 44•20 years ago
|
||
*** Bug 232514 has been marked as a duplicate of this bug. ***
Comment 45•20 years ago
|
||
*** Bug 277471 has been marked as a duplicate of this bug. ***
Comment 46•20 years ago
|
||
I have reproduced slightly alternate behaviour related to this bug which may
help under the Solaris builds of Moz and FF. If I set a style change for
background-color on the :focus pseudo-event to a single-line select box then
when the box is focussed the style change is correctly implemented. If the
focus change was achieved via any other means than by mouse-click, then all
remains well. However, if focus was by mouse-click, the expected behaviour of
opening the list does not occur *visibly*. However, the control acts as if this
has occurred, requiring a further two clicks or close-open keystrokes to
invisibly close and finally visibly open the select pane.
Comment 47•20 years ago
|
||
*** Bug 294390 has been marked as a duplicate of this bug. ***
Comment 48•20 years ago
|
||
Quite a few comments suggest it doesn't occur with GTK2. However I can confirm
with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421
Firefox/1.0.3 (Debian package 1.0.3-2), that's a GTK2 build. I don't think it
matters what the parent tag is either, I can reproduce with a <div> container
(http://jon.dowland.name/code/bugs/select-parent-hover.html)
Comment 49•20 years ago
|
||
> matters what the parent tag is either, I can reproduce with a <div> container
> (http://jon.dowland.name/code/bugs/select-parent-hover.html)
that's a completely different bug because the :hover applies to the div and not
the form control itself. And the <div> /is/ required (it would be a very boring
testcase without it).
Comment 50•20 years ago
|
||
(In reply to comment #48)
> Quite a few comments suggest it doesn't occur with GTK2.
I'll try to clarify this. It seems there are three issues mentioned in this
single bugzilla entry: 1. the original bug, 2. the one from comment #25, and 3.
the one from comment #48.
1. The original bug (SELECT with :hover, :focus) occurs in Gtk2 (see the version
details below), though not exactly as described in attachment (id=95883): The
first SELECT (plain) in that attachment pops-up correctly, the second one
(:focus) needs three clicks to pop up, the third one (:focus, :hover) behaves
correctly, the fourth one (:focus, :hover, :focus:hover) needs three clicks.
Interestingly, once tripple-clicked, the second and fourth SELECTs behave
correctly until you reload the page. There is a tiny issue with :hover already
covered in (now orphaned) Bug 37495.
2. The bug described in comment #25 (i.e., plain SELECT in TABLE/TR/TD with
:hover; also refered to in comment #32) does not occur in current Gtk2 (as noted
in comment #40). The SELECT works fine in the attachment (id=130550), even with
:hover on TD, or with the TABLE removed completely and SELECT placed in a DIV
with :hover. The tiny issue mentioned above applies here as well.
3. The bug from comment #48:
> However I can confirm
> with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421
> Firefox/1.0.3 (Debian package 1.0.3-2), that's a GTK2 build. I don't think it
> matters what the parent tag is either, I can reproduce with a <div> container
> (http://jon.dowland.name/code/bugs/select-parent-hover.html)
It really does not matter what the parent element is. But it does matter what
you do with the parent on hover. If you just change the background color (as in
attachment (id=130550)) or change/add a border, the select inside behaves
correctly. On the other hand, if you show the otherwise hidden select
(http://jon.dowland.name/code/bugs/select-parent-hover.html), the select needs
two (not three as in the original bug!) clicks to pop up its menu. Once
double-clicked, the select works fine until it is hidden again.
To sum up: Comment #25 looks as a Gtk1 or old Gtk2 problem, and is gone now.
In the original bug, and the one from comment #48, different number of clicks
are needed to pop up the select. This provides some evidence to the claim from
comment #49, that these issues are not related.
Versions:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4
(Debian package 1.0.4-2)
ii libgtk2.0-0 2.6.8-1 The GTK+ graphical user interface library
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries and Timezone
Comment 51•19 years ago
|
||
I've found a little workaround for the original problem (three clicks select item with :focus and :hover under linux), it's only works, when the :focus is the first definition in ths CSS section:
errorneous:
SELECT:hover { background-color: #A0C0F0; }
SELECT:focus { background-color: #F0F0F0; }
correct:
SELECT:focus { background-color: #F0F0F0; }
SELECT:hover { background-color: #A0C0F0; }
I hope, this helps in fixing the bug. :)
Comment 52•19 years ago
|
||
I've attached a simple testcase that only uses :focus. It requires three clicks on the down arrow to show the drop-down.
Tested in "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051210 SeaMonkey/1.5a" and "Mozilla/5.0 (X11; U; Linux i686; sv-SE; rv:1.8) Gecko/20051111 Firefox/1.5". These are GTK2 builds.
Comment 53•19 years ago
|
||
*** Bug 250810 has been marked as a duplicate of this bug. ***
Comment 54•19 years ago
|
||
*** Bug 320849 has been marked as a duplicate of this bug. ***
Comment 55•19 years ago
|
||
could you please stop to search for work-arounds and keep telling me, that even with your buggy software i don't need more than three clicks to open the select.
the standard says, that the select box is open after the first click, whatever the CSS may be.
please correct the bug.
suomi
Comment 56•19 years ago
|
||
For what it's worth, Mac Firefox 1.0.2 does not display this problem. So it seems to be Linux only.
Comment 57•19 years ago
|
||
Fixed by the checkin for bug 281551.
Comment 58•19 years ago
|
||
You sure? That patch is GTK2-only, and this bug was present with both GTK1 and GTK2. Did you actually test both?
Comment 59•19 years ago
|
||
Reopening pending a fix for gtk1.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•19 years ago
|
Assignee: blizzard → nobody
Status: REOPENED → NEW
QA Contact: ian → gtk
Summary: Using :hover and (or) :focus and (or) :active on select fields makes them almost unusable → [gtk1] Using :hover and (or) :focus and (or) :active on select fields makes them almost unusable
Comment 60•18 years ago
|
||
*** Bug 352481 has been marked as a duplicate of this bug. ***
Comment 61•18 years ago
|
||
*** Bug 354482 has been marked as a duplicate of this bug. ***
Comment 62•18 years ago
|
||
*** Bug 348430 has been marked as a duplicate of this bug. ***
Comment 63•18 years ago
|
||
Given that GTK1 support is being dropped....
Status: NEW → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → WONTFIX
Comment 64•18 years ago
|
||
Except it also happens with GTK2
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 65•18 years ago
|
||
Actually no. It doesn't. See comment 57.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•