83963 - Dragging links into frames does not work correctly (loads link in full window instead of targeted frame)

Status: VERIFIED WONTFIX

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Aaron Kaluszka]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010603
BuildID:    2001060320

Links that are dragged from one frame to another load the page in the full
window instead of a frame

Reproducible: Always
Steps to Reproduce:
1. Open page with frames with links
2. Drag link from one frame to another


Actual Results:  Link is loaded in full browser window

Expected Results:  Link should be loaded in frame in which it was dragged into.

Comment 1

[Andreas M. "Clarence" Schneider]

I like the current behavior very much. In NS 4.x I have to close a window and
open a new one if I want to drag a link into a window with frames. If the link
originates in the same window this may not be expected, but do we know where a
dragged link comes from?

Comment 2

[Aaron Kaluszka]

It should do it "the way you like it" if dragged into the address bar, but if
dragged into a frame, it should only load into the frame that its dragged into.
 Of course the drag into URL bar doesn't work right either.. separate bug.

Comment 3

[Aaron Kaluszka]

anybody looked at this yet?

Comment 4

[Kevin McCluskey (gone)]

Bulk reassignin HTML FRAME/IFRAME bugs to Eric.

Comment 5

[Eric Vaughan]

targeting

Comment 6

[Kevin McCluskey (gone)]

Bulk re-assigning all of Eric's HTMLFrame bugs to John.

Comment 7

[Donovan Warren]

This looks like the bug that's closest to the behavior I see, rather than a new bug:

After drag-selecting links in Mozilla (MAC and WINDOWS both have this behavior),
the first attempt to drag the selected link to an already-existing tab usually
fails.

In fact, attempting to drag the selected link _at all_ seems to fail. I usually
have to attempt a second (sometimes third or fourth) drag, and then I get the
correct response (cursor changes to indicate whether the link can be dropped or
not).

Current browser: 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Comment 8

[Donovan Warren]

After some additional testing, it looks like click-and-drag of a link,
previously selected or not, fails ~90% of the time _iff_ the attempted
click-and-drag goes north-south on the webpage (I.e., click- to click-and-drag
on the link, then drag toward the top of the window), but succeeds _iff_ the
attempt goes east-west.

Comment 9

[Aaron Kaluszka]

That has nothing to do with this bug.  File a new one if you wish.

Comment 10

[Boris Zbarsky [:bzbarsky]]

I strongly feel this should be wontfix.  Most of the time users neither care,
nor indeed know that a site is using frames.  So they'll drag a URL into the
browser expecting it to work like normal, and it won't.  Which is very bad UI.

Comment 11

[Johnny Stenback (:jst)]

I agree.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Ok.  Marking so.

Comment 13

[Aaron Kaluszka]

Your argument works for URLs dragged into the window from outside, but this is
for a frames page where links are dragged from one frame to another in the same
window.

Comment 14

[Boris Zbarsky [:bzbarsky]]

In that case, absolutely nothing should happen, imo, just like it currently
works for dragging things within a single page.  Again, since that's what users
will expect.  See bug 53376.

Comment 15

[Aaron Kaluszka]

Well since that's what IE does, I guess this 4.x "feature" probably hasn't been
used for a while. 
v.

Comment 16

[[e-mail]]

bz, if I drag a link it becomes droppable as soon as I change frames;
are you saying that that behaviour is in fact a bug?

Comment 17

[Boris Zbarsky [:bzbarsky]]

Neil, not only is it a bug, but I checked in the fix for it last night.

Comment 18

[Aaron Kaluszka]

Boris, you said you checked in a fix for comment 16.  I don't see this in
Firefox 20040509.  Did it get backed out or not applied to Firefox?  Is there a
bug number for that?

Comment 19

[Boris Zbarsky [:bzbarsky]]

The bug number is bug 53376 (blocking this bug and all).  It's code that should
be used by Firefox; make sure you're testing trunk builds.  If it's not working,
file a bug on Firefox.