137067 - Button don't show the "pressed" state

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Gilles Durys]

2002041200 cvs linux trunk

Open preferences.
Press on ok, cancel, help.

Expected results: button is shown pressed

Actual results: button does not change

It happens everywhere (browser,mail/news,address book) but only in Modern.
Classic is ok.

Comment 1

[Gilles Durys]

Build 2002040922 is ok.
Build 2002041022 is not.

Comment 2

[André Dahlqvist]

Can you give more detailed steps to reproduce? What exact panels under
Preferences do you visit to reproduce this?

Comment 3

[Gilles Durys]

Just open prefs and click on "ok" and keep your mouse button pressed.

Normally the "ok" button should be drawn lowered like
http://mozilla.durys.net/button_ok.png .
With my build, it isn't being drawn differently.

It only happens on a trunk build in modern.
Classic is ok.
1.0 branch is ok (both modern and classic).

Comment 4

[R.K.Aa.]

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

Comment 5

[R.K.Aa.]

OS: All. Related: bug 137124

Comment 6

[R.K.Aa.]

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

Comment 7

[Robert Kaiser]

It looks this was caused by bug 5693, probably it should go to dbaron, who fixed
that one.
I'm also seeing this on my development tree of EarlyBlue skin, I'm not sure why
this is working on Classic and failing for e.g. EarlyBlue, because I copied most
of the code from Classic and modified it only slightly...

It seems like :hover:active is not working correctly on the button element...

Comment 8

[Robert Kaiser]

I could fix this with inserting
@import url("chrome://global/skin/button.css");
into global/global.css in my own skin.

This isn't a really nice hack but working for me currently. It seems like CSS
rules in those files aren't picked up correctly...

I'll look if this does also help modern...

Comment 9

[Robert Kaiser]

hmm, this really helps. I see this plus the same hack for toolbarbutton cause
some positioning (non-:hover of :hover:active related) flaws though...

This isn't the ideal solution, that's clear. But it shows that the underlying
problem seems to be somewhere when applying style...

BTW, this really looks the same problem as bug 137069 and bug 137124, as I could
fix them with the same hack (that's why I also did it for toobarbutton).

We should really look what changes we have here between the builds mentioned in
Comment #1

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->me.  I have a fix.  See bug 137247 comment 2 for a description of the problem.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: fix

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh, I get it.  It actually was my fault, and I was just assuming that the
breakout optimization always worked.  So there is an alternate fix, which is
simpler.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: simpler fix

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: add comment to prevent the same mistake

Comment 17

[R.K.Aa.]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

So let me get this straight.  The reason this failed is that we'd be in 
WalkRuleProcessors, would call mStyleRuleSupplier->WalkRules(this, aFunc, 
aData);, that would set the mStateful bool to true, then we'd walk 
mDocRuleProcessors and that would clobber mStateful on the data?

If that's what's going on, r=bzbarsky.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yep.  Or different things within the stateful rule processors stuff would
clobber each other.

Comment 20

[Chris Waterson]

Comment on attachment 79155 [details] [diff] [review]
add comment to prevent the same mistake

sr=waterson

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2002-04-15 15:28 PDT.

Comment 22

[Robert Kaiser]

this appears fixed to me, shouldn't it be set to that state?

dbaron?

Comment 23

[Robert Kaiser]

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

Comment 24

[Jesse Ruderman]

Does this bug also cover the problem where buttons in dialogs never appear to 
be focused?

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is fixed since it was never a problem on the branch (see above).  I'll
remember to check it in on the branch when I land bug 5693 there.

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 27

[Koike Kazuhiko]

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