Closed Bug 38123 Opened 25 years ago Closed 24 years ago

Need to revert links back to original color after drag/drop

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.0

People

(Reporter: bugzilla, Assigned: mikepinkerton)

Details

Build ID: 2000050308 Steps to Reproduce: (1) Drag a link onto the toolbar (release the mouse when the standard "NO" cursor appears) The link remains the color it turned when the mouse was down on it, rather than reverting back to its normal color; it doesn't revert until a click on the scrollbar or in the content area.
Marc: this is either in style or UI. Please triage.
Assignee: rickg → attinasi
Same problem if the link is invalid; the link color does not change back until you click on the document or another link, or otherwise get the focus off of the dragged link. I'll look into it to see what's up.
Status: NEW → ASSIGNED
The problem appears to be that the EventStateManager is never being notified that the content element is no longer active, so it is being correctly styled in the active color. Clicking elsewhere causes a new active element, taking the old element out of the active state, so again it is correctly styled. We need to clear the content's active state after the drag. Forwarding to appropriate engineer when I find out who that is.
Making a guess that this might be one for Pinkerton... Please see my previous comment regarding the active state for the element not being cleared.
Assignee: attinasi → pinkerton
Status: ASSIGNED → NEW
Actually, this seems to just be a general problem with drag and drop -- even if the drop is successful, the color still won't change back (it seems). Resummarizing to reflect this...
Summary: Need to revert links back to original color after failed drag/drop → Need to revert links back to original color after drag/drop
odd, this works fine on mac. must be a problem with the dragexit not being sent or something. hmmmm. ok. i'll bite, but not a high priority.
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
massive update for QA contact.
QA Contact: petersen → lorca
Severity: normal → trivial
Target Milestone: Future → mozilla1.0
not seeing this anymore
yeah, we changed the selection behavior with link dragging so that the link is now selected when it's dragged, so i guess we can't see if it is focussed or active. WFM?
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
VERIFIED on Mac OS 9.0.4 10-24-08 branch bits. Trunk anyone?
Keywords: vtrunk
vrfy wfm in new winME build. the problem is just masked, as pink said, but I think this is a dup of bug 48857 anyways (in which case attinasi's 5/04 comment might be helpful) oh, hiya pink!
Status: RESOLVED → VERIFIED
SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.