37201 - a without href is draggable, acts like href="./" when dragged

Status: VERIFIED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Jesse Ruderman]

Steps to reproduce:

1. Create an html document: <a>some text inside an a tag without an href</a>
2. Try selecting the text.

Expected result: 

Text acts as if <a> tag wasn't there when you click or drag it.

Actual result: 

After a few pixels of selecting, mozilla decides that you're trying to drag a 
link.  When you let go of the mouse button, it extends the selection to where 
you dropped it and then goes to the index file of the directory the file is in.

Note: 

This bug doesn't seem to happen with data: urls, although I wasn't able to test 
the effect of <base href=...> on this peculiarity because of bug 37200.

Comment 1

[Jesse Ruderman]

Attachment: for those too lazy to create an html file with <a>some text</a>

Comment 2

[Sean Richardson]

These problems exist in the 2000-04-25-12-M16 nightly binary on WinNT.

Problem 1: <a>text</a> is taking on some but not all of the expected behaviours
of an <a> element with an attribute. 

According to the HTML 4.01 spec, just below the attribute list at 
<URL:http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2>,
 > Authors may also create an A element that specifies no anchors, i.e., that 
 > doesn't specify href, name, or id. Values for these attributes may be set 
 > at a later time through scripts.

IMO ideally an <a> element with no href, name, or id attributes should be
as active as a <foo> element, and once one of those attributes is set by
scripting or any other sort of DOM manipulation, it should work as if it had
always been set by an attribute. The complementary case of an <a> losing its
href, name, and/or id by DOM manipulation would also be covered by making this 
element's behaviour dependent on the presence or absence of those attributes.

If that's not possible, perhaps such an anchor could be treated as if it had a 
'name=""' attribute initially.

If an <a> element with no attributes were inactive, there would be nothing 
to drag.

Problem 2:
Dragging an anchor from one place to another in the content area is activating
that link, no matter what attributes it may have. See testcase to follow to
confirm this. Surely this will be fixed by the people working on drag-n-drop:
in NN 4.x and earlier, such a drag is forbidden -- the drag must go somewhere
else to do anything. 

Problem 1 might be related to bug 36826, "named anchors no longer work", 
nsbeta2+, if it was not happening earlier -- they are also acting like 
href="./".

Comment 3

[Sean Richardson]

Attachment: <a> elements with no, name="blah", name="", and href="#blah" attributes

Comment 4

[Jesse Ruderman]

The second problem you mentioned is bug 36867.

Comment 5

[rickg]

It's hard to tell what this bug is all about, but I think it's a selection/drop 
problem. MJudge, is this yours?

Comment 6

[rubydoo123]

setting to m18

Comment 7

[mjudge]

i may be ignorant but please retest this. besides number 4, everything seems 
fine. i can select 1-3 without causing a drag.

Comment 8

[Sean Richardson]

Mike, FWIW I'm pretty sure that this specific problem, selecting text in any 
<A> acting like dragging a link, only happened because of other bugs that made
<A> elements work mucho weirdo for a while... not all of which are mentioned 
here. There *was* a distinct usability problem here, but probably not a
distinct code problem.

Comment 9

[Jesse Ruderman]

wfm too

Comment 10

[gerardok]

massive update for QA contact.

Comment 11

[Keyser Sose]

Works for me:
Platform: PC
OS: Windows 98
Mozilla Build: 2000101014 M18 Trunk Build

Marking as Verified.

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.