Open
Bug 379272
Opened 18 years ago
Updated 2 years ago
Dragging and dropping a non-button element leaves it matching :active
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
NEW
People
(Reporter: xavier, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 XPCOMViewer/0.9.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 XPCOMViewer/0.9.5
I've set up a drag and drop handler on a label, and used css styles so that the label has a different color when it's ":hover" and ":active"
When I click and hold, it turns to the ":active" defined color, then I move the pointer and drop it anywhere (on the location bar for instance).
The color of the label remains the one defined in the ":active" style (and in DOM inspector, the css rule shows that :active is still taken into account.
Reproducible: Always
Steps to Reproduce:
1. set up and startdrag handler on an element with an :active style
2. Drag and drop the element
3.
Actual Results:
The active style remains even when element is no longer selected
Expected Results:
The element should be reset to its default style
|
||
Comment 1•18 years ago
|
||
can you please attach a minimal testcase that shows this problem? ('Add an attachment' above)
install the xpi, restart, then call URI chrome://test/chrome/test.xul
Drag the label, drop it, it remains red, as defined in the :active style
(style are declared with a data: protocol, but it is the same with a separate style sheet, I just made it as compact as possible).
|
||
Updated•18 years ago
|
QA Contact: general → drag-drop
|
||
Comment 4•16 years ago
|
||
|
|
||
Comment 5•16 years ago
|
||
I'm not sure what component this bug should be in.
Blocks: 225434
Status: UNCONFIRMED → NEW
Component: Drag and Drop → Layout
Ever confirmed: true
OS: Windows XP → All
QA Contact: drag-drop → layout
Hardware: PC → All
Version: unspecified → Trunk
|
||
Updated•16 years ago
|
Flags: wanted1.9.2?
|
||
Updated•16 years ago
|
Summary: Drag and dropping an non-button element does not reset the :active pseudo class → Dragging and dropping a non-button element leaves it matching :active
|
|
||
Comment 6•15 years ago
|
||
Whatever component owns nsEventStateManager.cpp :-)
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2-
|
||
Comment 7•14 years ago
|
||
Bug 593959 should fix attachment 323590 [details], at least on Linux. Haven't tested
OSX/Windows
Depends on: 593959
|
||
Comment 9•13 years ago
|
||
It should block bug 675925, just like bug 666864 does.
|
|
||
Comment 10•13 years ago
|
||
oops, read bug 675925 as bug 674925
|
|
||
Updated•12 years ago
|
|
|
||
Comment 12•4 years ago
|
||
There is a very old patch in bug 851103 for this but it got stuck on lack of tests.
|
||
Updated•2 years ago
|
Severity: normal → S3
|
||
Comment 18•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates.
:dholbert, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(dholbert)
|
||
Comment 19•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Flags: needinfo?(dholbert)
You need to log in
before you can comment on or make changes to this bug.
Description
•