:-moz-drag-over doesn't work on chrome

NEW
Unassigned

Status

()

defect
P4
normal
20 years ago
6 years ago

People

(Reporter: mikepinkerton, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.2 -

Firefox Tracking Flags

(Not tracked)

Details

make sure rod hooked up :drag-over correctly. I don't think he did, but i could
be reading the code incorrectly.
m10.
Target Milestone: M10

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Blocks: 12666

Updated

20 years ago
Assignee: hyatt → pinkerton
Status: ASSIGNED → NEW
Target Milestone: M10 → M14

Comment 2

20 years ago
reassigning to pink for m14
accepting
moving dogfood-related d&d stuff back to M12. woohoo!

Comment 5

20 years ago
mass-moving all m12 bugs to m13

Comment 6

20 years ago
dividing up phillips qa contact bugs, he no longer works here

Comment 7

20 years ago
drag&drop is once again post-beta according to marketing. moving all d&d bugs to
M15.
not essential.
Target Milestone: M15 → M17

Comment 9

19 years ago
Mass moving M17 bugs to M18
Target Milestone: M17 → M18

Comment 10

19 years ago
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
all the code appears to be written, but for some reason the state isn't always
being set in the ESM. we only set it when the handling of the dom event !=
consumeNoDefault, which is never the case when we're over the chrome for drag
events.

a good testcase of this is to change ben's rules for the home button in
  mozilla/themes/modern/communicator/button.css
to use :drag-over instead of having the JS set an attribute.

cc'ing saari.
Keywords: nsbeta3
Summary: verify :drag-over done correctly → :drag-over doesn't work on chrome

Comment 12

19 years ago
adding nsbeta3+  -- part of basic toolkit functionality 
Keywords: correctness
Priority: P3 → P4
Whiteboard: nsbeta3+
alas, I don't think i'll be able to get to this. futuring.
Target Milestone: M21 → Future
Whiteboard: nsbeta3+ → nsbeta3-
Target Milestone: Future → mozilla1.0

Updated

19 years ago
QA Contact: elig → jrgm
-> me for investigation
Assignee: pinkerton → ben
Status: ASSIGNED → NEW
Boy do I suck. Accepting. I'll get to this some day. 
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → Future
Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com
Assignee: bugs → ben_seamonkey
Status: ASSIGNED → NEW
Assignee: ben_seamonkey → jag
QA Contact: jrgmorrison → xptoolkit.widgets
Assignee: jag → nobody
Whiteboard: nsbeta3- → nsbeta3- [expired?]
psuedo class was renamed to -moz-drag-over, but still doesn't work on chrome afaict.
Component: XUL → Style System (CSS)
Flags: wanted1.9.2?
QA Contact: xptoolkit.widgets → style-system
Summary: :drag-over doesn't work on chrome → :-moz-drag-over doesn't work on chrome
Whiteboard: nsbeta3- [expired?]
Target Milestone: Future → ---
Component: Style System (CSS) → XUL
QA Contact: style-system → xptoolkit.widgets
The check that pink mentioned in comment 11 is still in nsEventStateManager::FireDragEnterOrExit .

I also think :-moz-drag-over should probably be hierarchical just like :active and :hover.  (This involves changing nsEventStateManager::GetContentState and nsEventStateManager::SetContentState.)

We might also want to make sure that nsEventStateManager::GenerateDragDropEnterExit makes sense.
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2-

Comment 19

7 years ago
Apparently works on chrome now, at least for me.  Are there also cases where it doesn't work?

Comment 18 still applies though.  This selector is useless as currently implemented, due to not selecting when dragging over anonymous children (or any other children for that matter).  Perhaps this is masking the fact that it actually does work in its own limited fashion?
It doesn't appear to work for background-image (at least when using a gradient), and the same applies in Postbox. Can be tested by using QuickFolders and setting a palette entry for the drag over style.
(In reply to Axel Grude [:realRaven] from comment #20)
> It doesn't appear to work for background-image (at least when using a
> gradient), and the same applies in Postbox. Can be tested by using
> QuickFolders and setting a palette entry for the drag over style.

Sorry. to be more precise: it works in Thunderbird (chrome) but not in SeaMonkey and Postbox (chrome). I am adding the dragover rules dynamically.
You need to log in before you can comment on or make changes to this bug.