Closed Bug 102896 Opened 23 years ago Closed 22 years ago

alternates with duplicate URIs ignored on the link toolbar

Categories

(SeaMonkey :: UI Design, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.1alpha

People

(Reporter: ian, Assigned: choess)

References

()

Details

(Keywords: testcase)

Attachments

(1 file, 2 obsolete files)

STEPS TO REPRODUCE
   http://www.bath.ac.uk/~py8ieh/internet/eviltests/link1.html
   Click on Link Toolbar: More | Other Versions.

ACTUAL RESULTS
   One link appears.

EXPECTED RESULTS
   Multiple links should appear, one for each language.

cc'ing usual suspects as per bug 102832.
Keywords: testcase
Blocks: html4.01
Summary: Only one "alternate" <link> is displayed → Only one "alternate" <link> is displayed on link toolbar
We probably don't do the right thing for rel="alternate" yet; this is definitely
multi-valued. I can't see how this works straight off; let's see if one of the
other coders on this toolbar can figure it out :-) It could be related to
hewitt's reformatting of the JS.

Gerv
cool new feature!

->claudius, since he tests toolbars.
QA Contact: sairuh → claudius
I can reproduce this with the URL given, but http://dopefishjustin.tripod.com/
displays the correct number of alternate pages (two).
We used to DTRT for "alternate", but that got stripped out in one of the various 
rewrites.  It shouldn't be that hard to reassemble.  BTW, I'm attaching various 
link toolbar bugs to 87428 for convenience of tracking, even though that bug is 
closed.

Justin: I think you may want to use the "hreflang" rather than the "lang" 
attributes in your example...
Blocks: LinkUI
(/me reads W3C specs for LANG)
Hm! Did not know there was an hreflang attribute. I'll leave the page alone
until this bug is fixed, though.
This bug is either INVALID or an edge-case RFE. The reason Hixie's test case is
not working is because all the <link>s link to the same dummy page. I'm assuming
the Links Toolbar is noticing this and not adding them again.

You could argue that there's a case for changing the behaviour to add extra
links even if they are both rel="foo" and both href="bar.html" but that would be
an edge case RFE.

Chris: please don't spam all the people on bug 87428 by using it for dependency
tracking. That is not the way to use a closed bug. If you want to file a
meta-bug, please feel free to do so.

Gerv
No longer blocks: LinkUI
Severity: major → minor
OS: Windows 2000 → All
Hardware: PC → All
There is nothing in the spec that says that links pointing to the same URI should
in any way be considered related to each other.

If I have

   <link rel="alternate" href="foo" title="Gibberish Version">
   <link rel="alternate" href="foo" title="Disassociated Press Version">

...then it should work, showing two alternate versions. We already have a bug with
multiple bookmarks with the same URI being impossible, let's not repeat the bug
with the link toolbar... However, this is indeed a trivial bug! :-)
Severity: minor → trivial
Summary: Only one "alternate" <link> is displayed on link toolbar → alternates with duplicate URIs ignored on the link toolbar
Blocks: 103053
I've slapped up a quick patch for this, but I haven't tested it yet.
Assignee: drbrain-bugzilla → choess
Keywords: patch
Is there another part of the implementation that depends on the items in the
toolbar having unique URLs?  Looks good to me if not.
Oops, missed a spot.  This should be fine for testing now (i.e., no js errors),
but I have no idea what it will do to the implementation...I'm waiting to test
until some of the patches in my local tree get checked in.
Looks good to me. I'll r= it when it's easier to test it (fewer patches in local
tree.)

Gerv
Gerv, can you give this r= now that 0.9.5 has branched?
Status: NEW → ASSIGNED
Keywords: review
Priority: -- → P5
Target Milestone: --- → mozilla0.9.6
Can you get one from sballard? :-) I will if there's no-one else.

Gerv
Can someone give r= on this? sballard's been away...
r=gerv, presuming you've actually tested this.

Gerv
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Attachment #52157 - Attachment is obsolete: true
The Target Milestone (0.9.7) is passed.  This bug should be retargeted.
There is a reviewed patch attached.  If it is still valid, perhaps just
sr= and a= are required?
choess: any progress on this? Should at least be retargeted to something later
than 0.9.7 no?
Keywords: mozilla1.0
I'm not going to try to get sr= until after we branch for 1.0.
Keywords: mozilla1.0
Target Milestone: mozilla0.9.7 → mozilla1.1
remove self
Attached patch Updated patchSplinter Review
Attachment #52171 - Attachment is obsolete: true
Attachment #112634 - Flags: superreview?(jaggernaut)
Attachment #112634 - Flags: review?(timeless)
Attachment #112634 - Flags: review?(timeless) → review+
Comment on attachment 112634 [details] [diff] [review]
Updated patch

sr=jag
Attachment #112634 - Flags: superreview?(jaggernaut) → superreview+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: