282685 - Anchor Tag Ignored in TD Block

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Robert Sugg]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217

  I use the Bluefish HTML editor to maintain barebones photo album pages. These
pages consist of a goto table and a large image table with multiple TR's each
containing one TD. Each TD block has : anchor, image, image, anchor w/ image.
The second anchor tag gets dropped by Mozilla 1.7.5 and Firefox 1.0 on all rows
except for the first one. (Oddly enough a partially loaded page shows the second
anchor tag properly).
  This quirk persists even if I remove the first anchor tag and replace it with
an ID attribute in the TD tag. I have also tried wrapping the image tags with
their own anchor tags (anchor, [anchor w/ image] * 3). Also, when I fired up
your Composer component it reported the first anchor tag with an anchor symbol
and any trailing anchor tags with a "A" block.
  The page passes the Tidy HTML checker and Konqueror (KDE's browser) does
render the second anchor tag.

Reproducible: Always

Steps to Reproduce:
1.Create an HTML page.
2.Add a table.
3.Insert several rows (TR's) into the table. 
<tr> <td align="center">
<a name="BIG_01"> 01 </a>
<img src="Sample_files/Thumb_1.jpg" alt="Thumb : 01" border="0">
<img src="Sample_files/Large_1.jpg" alt="Full : 01" border="0">
<a href="#TOP"><img src="UpArrow.jpg" alt="Top" border="0"></a></td></tr>
<tr> <td align="center">
<a name="BIG_02"> 02 </a>
<img src="Sample_files/Thumb_2.jpg" alt="Thumb : 02" border="0">
<img src="Sample_files/Large_2.jpg" alt="Full : 02" border="0">
<a href="#TOP"><img src="UpArrow.jpg" alt="Top" border="0"></a></td></tr>
<tr> <td align="center">
<a name="BIG_03"> 03 </a>
<img src="Sample_files/Thumb_3.jpg" alt="Thumb : 03" border="0">
<img src="Sample_files/Large_3.jpg" alt="Full : 03" border="0">
<a href="#TOP"><img src="UpArrow.jpg" alt="Top" border="0"></a></td></tr>
Actual Results:  
Firefox - no trailing anchors rendered.
Mozilla - only renders first trailing anchor.
Composer - as described in "Details".
Note - Both Firefox and Mozilla tended to stall partway through a page re-load
(new tab, open file, upon load complete hit "Reload" button). When either
browser stalled all of the trailing anchor tags would be rendered.

Expected Results:  
Rendered the second (or trailing if ID is used) anchor block. This would show :
label, thumbnail image, full-size image, return-to-top button.

Comment 1

[Gérard Talbot]

> Each TD block has : anchor, image, image, anchor w/ image.

<a name="BIG_01"...>, <a name="BIG_02"...> are anchors; 
<a href="#TOP"...> is a link.

> The second anchor tag gets dropped by Mozilla 1.7.5 and Firefox 1.0 on all rows
> except for the first one. 

We would need to examine this in a real page.

>   This quirk persists even if I remove the first anchor tag and replace it with
> an ID attribute in the TD tag. 

You gave no url showing the problem. You attached no reduced testcase showing
the problem. Best is to attach a reduced testcase:
What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

>   The page passes the Tidy HTML checker and Konqueror (KDE's browser) does
> render the second anchor tag.

Good. What's the url?
 
> Composer - as described in "Details".
What do you mean?

> Rendered the second (or trailing if ID is used) anchor block.
What do you mean by trailing or trailing anchors?

Comment 2

[WADA:World Anti-bad-Duping Agency]

> return-to-top button
Reporter, do you define anchor named "TOP"?
Don't you misundertand that href="#TOP" means top of page? 
IE probably jumps to top of page if no anchor is defined, but Mozilla probably
stays here.
This is same when <a href="#">, probably. 

Comment 3

[Boris Zbarsky [:bzbarsky]]

No testcase, no usable steps to reproduce, no response to Gérard's questions for
a week.

Marking invalid, but please reopen when you attach a testcase showing the problem.

Comment 4

[Robert Sugg]

Attachment: Sample Page For 3 Image Pairs

Comment 5

[Robert Sugg]

**************************************
* E-mail input seems to be disabled. *
**************************************

From: Robert Sugg <[e-mail]>
To: [e-mail]
Subject: Re: [Bug 282685] Anchor Tag Ignored in TD Block
Date: Fri, 18 Feb 2005 23:14:54 -0800

Test Case: My sample page (Sample.html) is attached - I suspect you have
some misc. images that you could rename to fit (see below for names) and
place in a folder called "Sample_files". 

Image Pairs:
Thumb_1.jpg / Large_1.jpg
Thumb_2.jpg / Large_2.jpg
Thumb_3.jpg / Large_3.jpg

Composer Glitch: I tinkered with my test case and found that the glitch
is an undocumented feature of the Composer component. The help text on
creating links (Index -> Composer -> creating links) explains what the
anchor symbol means. It doesn't explain what a nameless anchor tag is
represented by - namely an "A" on a yellow square. Perhaps you could
pass along a suggestion to the documentation person / team on this
point.

Trailing Anchor: Each of my TD (Table Data) blocks has four pieces -
        1) A leading anchor tag used as an anchor (anchor-anchor);
        2) An image link to a thumbnail;
        3) An image link to the full-size image;
        4) A trailing anchor tag used as a link (anchor-link).


On Fri, 2005-02-18 at 20:32, [e-mail] wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=282685
> 
> 
> [e-mail] changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |[e-mail]
>            Keywords|                            |qawanted
> 
> 
> 
> 
> ------- Additional Comments From [e-mail]  2005-02-18 20:32 PST
-------
> > Each TD block has : anchor, image, image, anchor w/ image.
> 
> <a name="BIG_01"...>, <a name="BIG_02"...> are anchors; 
> <a href="#TOP"...> is a link.
> 
> > The second anchor tag gets dropped by Mozilla 1.7.5 and Firefox 1.0 on all rows
> > except for the first one. 
> 
> We would need to examine this in a real page.
> 
> >   This quirk persists even if I remove the first anchor tag and replace it with
> > an ID attribute in the TD tag. 
> 
> You gave no url showing the problem. You attached no reduced testcase showing
> the problem. Best is to attach a reduced testcase:
> What is a Simplified Test Case, and How Do I Make One?
> http://www.mozilla.org/newlayout/bugathon.html#testcase
> 
> >   The page passes the Tidy HTML checker and Konqueror (KDE's browser) does
> > render the second anchor tag.
> 
> Good. What's the url?
>  
> > Composer - as described in "Details".
> What do you mean?
> 
> > Rendered the second (or trailing if ID is used) anchor block.
> What do you mean by trailing or trailing anchors?
> 

*****************************************************************
End of reply #1
-----------------------------------------------------------------
Start of reply #2
*****************************************************************
From: Robert Sugg <[e-mail]>
To: [e-mail]
Subject: Re: [Bug 282685] Anchor Tag Ignored in TD Block
Date: Sat, 19 Feb 2005 09:10:42 -0800

1) "TOP" is defined as an ID attribute in a CENTER tag (line 7).
2) I'm on a Linux rig (SUSE 9.1 Pro) without MSIE.
3) I'm reporting that the link does NOT get rendered or displayed - not
that it fails to work (how can it fail if it isn't on the page ?). 
4) By the way here's the browser scoreboard :
---------------------------------------------
Mozilla 1.7.5  - no show
Mozilla 1.7.3  - no show
Firefox 1.0    - no show
Mozilla 1.6    - works (default copy that came w/ SUSE 9.1 Pro)
Konqueror 3.3  - works
Opera 7.54     - works 
Galeon 1.3.12  - works
Epiphany 1.0.7 - works
---------------------------------------------
DIJA,
Kay-Sugg

On Fri, 2005-02-18 at 23:54, [e-mail] wrote: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=282685
> 
> 
> 
> 
> 
> ------- Additional Comments From [e-mail]  2005-02-18 23:54 PST -------
> > return-to-top button
> Reporter, do you define anchor named "TOP"?
> Don't you misundertand that href="#TOP" means top of page? 
> IE probably jumps to top of page if no anchor is defined, but Mozilla probably
> stays here.
> This is same when <a href="#">, probably. 
> 
> 

**********************************************************
End of manual forwarding

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
> Created an attachment (id=175499) Sample Page For 3 Image Pairs
Robert Sugg, What is your current problem on your test page?
Can you attach screen shot?

> Mozilla 1.6    - works (default copy that came w/ SUSE 9.1 Pro)
Did you uninstall pre-packaged Mozilla 1.6 before 1.7.5 install?

Comment 7

[Boris Zbarsky [:bzbarsky]]

I do see the problem in Firefox 1.0, but not in a current trunk Mozilla build --
there all three anchors render fine.

Comment 8

[WADA:World Anti-bad-Duping Agency]

Attachment: Screen shot of test-case on Firebird 1.0.1(narrowed window)

This is screen shot of test case of your attachment (id=175499) with Firebird
1.0.1(release build,Installer) on Win-2K, with narrowed window width.
Last text link of "Top"(ALT is displayed) was moved to next line, but latter
half of "Full: 01"(":01" portion) went outside of window.

Since last "Top" link becomes text link instead of image link when the test
case, your result in real case is possibly different.
But this phenomenon seeme to has relation to this bug's probem.

Robert Sugg, does your table width in real case is wider than window width?
Boris, is your problem on Firefox similar one to mine?

Comment 9

[Robert Sugg]

Attachment: Sample Page For 3 Image Pairs w/ Images

Updated Sample.html to include browser info.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> Boris, is your problem on Firefox similar one to mine?

No.  My problem (and presumably Robert's) with Firefox 1.0 is that the second
and third "Top" links simply do not render at all.

I see the same problem on attachment 175537 [details], but again only with Firefox 1.0.  A
current trunk Firefox (and current trunk Mozilla) renders fine.

Given that, marking worksforme.

Comment 11

[Robert Sugg]

Attachment: Two Snapshots - 196k Tar Ball

Here are two snapshots of Mozilla 1.7.5 and FireFox 1.0 (Moz. 1.7.3 equiv.).
This shows that in going from v1.6 to v1.7.x something was broken in the HTML
renderer.

Comment 12

[Robert Sugg]

SUMMARY
=========
1) The two current forks of Mozilla (v1.7.5 and FireFox 1) have a broken renderer.
2) A previous release (v1.6) worked fine.
3) Alternate browsers (Opera, Konqueror, etc.) also work fine.
4) Also, what about the stall on reload ?

Add. Background
===============
All four versions of Mozilla are in different directories. This makes for some
headaches with plugins.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Robert, I agree there is a problem in 1.7.5.  Again, the problem is fixed in
current development builds.  You can get one at
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk if you want
to test it.

Comment 14

[Robert Sugg]

Attachment: Snapshot of FireFox 1.0.1

Snapshot of FireFox 1.0.1 - just installed this morning. It's another NO SHOW.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Yes, 1.0.1 uses the same rendering engine as 1.0 and 1.7.5.

Comment 16

[Robert Sugg]

After downloading two pieces of the nightly build I got a working copy of 1.8b2
that :
a) rendered the trailing anchor tags; and
b) did NOT stall on reload.

This was tested on both my Sample.html page and a full size album page.
Thank you all for your time,
Kay-Sugg

Comment 17

[WADA:World Anti-bad-Duping Agency]

Just information.

(In reply to comment #10)
> > Boris, is your problem on Firefox similar one to mine?
> No.  My problem (and presumably Robert's) with Firefox 1.0 is that the second
> and third "Top" links simply do not render at all.

As you say, my problem in attachment 175524 [details] (screen shot) in comment #8 is found
to be different problem in very psecial case.

This was horizontal scroll bar display problem when window size was narrowed to
near minimum window width(too narrow. no space for tab close button, no space
for virtical scroll bar).
(No problem when window width is enough to hold a "tab title" and "tab close
button"/"virtical scroll bar".)
This was still observed on firefox/latest-trunk 20050225 build.