If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

hyperlinks dynamically created in div sections show up in most cases but not others

RESOLVED DUPLICATE of bug 102695

Status

SeaMonkey
General
RESOLVED DUPLICATE of bug 102695
13 years ago
13 years ago

People

(Reporter: Jim, Unassigned)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a3) Gecko/20040815 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a3) Gecko/20040815 Firefox/0.9.1+

If you look at the Cardinals depth chart page in the URL given, there is a
single javascript function, 'function printPosition(pos){...}', that is used to
dynamically create a list of links of each player. The function is called to
create a string that becomes the content of div sections that are placed are
specific locations on top of the background field image.

Every time I load the page, the same blocks' links don't work. These blocks are
1st base ('printPositions("1B");'), 2nd base ('printPositions("2B");'), and 3rd
base ('printPositions("3B");'). The calls to create these strings are not made
sequentially if you look at how the pages loads, and there are div blocks
created correctly before, after, and in between these are created.

All of this leads my spidey code sense to say (I wish I knew a way to step
through the JS myself and view variable contents in Firefox, perhaps you can
enlighten me on a way to do that) that this is rendering problem and not a
javascript engine issue.

FYI, this page does render correctly in IE 5.5 SP2.


Reproducible: Always
Steps to Reproduce:
1. Load the URL given.
2. Notice the 1st, 2nd, and 3rd base players don't have working hyperlinks.
3.



Expected Results:  
Correctly rendered hyperlinks for players in the form of...
http://stlouis.cardinals.mlb.com/NASApp/mlb/team/player.jsp?player_id=XXXXXX
where the X's are valid player id's set up in the javascript datastructure 'roster'.
(Reporter)

Comment 1

13 years ago
I just noticed that if you hold the cursor over the very right side of the 'n'
in S. Rolen's name on the 3rd base section of the page or in the 'y' in the J.
Mabry's name in the same section you can get to the hyperlink. So the JS
creating them is most certainly working correctly but the anchor tags must not
be rendered correctly to encompass the whole text of the link.
Summary: hyperlinks dynamically created in JS work in some cases and not others → hyperlinks dynamically created in div sections show up in most cases but not others

Comment 2

13 years ago
The containing divs for each position (1B, 2B, ...) are overlapping.  They're
each 200px wide, absolutely positioned and have the same z-index, and the order
in which the divs are created is significant (with respect to the reported issue).

This sounds like the correct behavior according to CSS2.  "Boxes with the same
stack level in a stacking context are stacked bottom-to-top according to
document tree order."  

see http://www.w3.org/TR/CSS2/visuren.html#stack-level
(Reporter)

Comment 3

13 years ago
I see this point but further along at the bottom of section 9.9.1 in the W3C
CSS2 doc, the notion of transparency is given. The following text seems to say
that anything rendered in a box below should still be visible if nothing
rendered in the box above actually overlaps, despite the fact that box borders
do in fact overlap, i.e. hyperlinks should still be clickable if they are not
covered by text/image/etc. from the above box.

"The default behavior of a box is to allow boxes behind it to be visible through
transparent areas in its content. In the example, each box transparently
overlays the boxes below it. This behavior can be overridden by using one of the
existing background properties."

Given that nothing (text/links/images) actually overlap, only box borders, this
to me is still indeed a bug.

Comment 4

13 years ago
"Visible" may be the key word.  There's still a block there, but its background
is transparent, permitting content behind is to be seen.  (If the background was
a solid color, the content behind it would be visually obscured as well, in
which case the observed behavior would be completely expected.)
(Reporter)

Comment 5

13 years ago
First off, let me just say, I'm not trying to be difficult, I'm trying to help.
With that in mind...

In the case that there is a background color, you are correct, the observed
behavior of the hyperlink would be entirely correct. But in the case at hand, it
is defined as transparent, and while you can SEE the text behind the box
(correct functionality thus far), I would think that the mere visibility of the
hyperlink would also allow its functinality.

Clearly, any sort of interactive element (i.e. hyperlink, form widget, etc.)
presented visually but without its functionality is going to confuse the average
user. I'm a developer and HTML and JS literate and it still confused me why the
links didn't work. I traced the problem as much as I could before I thought I
should submit it as a bug. It was only after the block rendering cause was
explained to me and I thought to turn on "Outline Block Level Elements" in the
devleoper toolbar that my confusion passed. The average user will simply think,
"this browser is broken, I guess its back to IE." Incidentally, I know several
people who have thought this exactly same thing and done just that with their
own experiences.

Are you trying to win hearts and minds or is this whole browser merely an
intelllectual exercize?

Now don't get me wrong, I'm not trying to tout M$ as being better, I want
Mozilla to supercede IE in every way which definitely on its way of doing. That
is the only reason I bothered to submit and pursue this. So let me reiterate one
point, IE renders the behavior the way I think it should be rendered and in the
way that will not confuse Joe User so I'm not the only one who thinks this is
the correct behavior.

The W3C document linked for me in a previous comment, based on the section I
quoted, does not clearly specify what should happen in this particular
situation. Is there some method to resolve this by asking the W3C what the
behavior should be? Perhaps coerce them to alter the doc to resolve the
ambiguity at some point also?

Thanks for listening.

Comment 6

13 years ago
Have a look at bug 102695.  In particular, see the "simplified testcase."  You
may wish review a few of the bugs marked as duplicates of it as well.  If that's
indeed the same issue, please resolve this one with "Resolve bug, mark it as
duplicate of bug # 102695."  (Sorry for not locating that sooner.)
(Reporter)

Comment 7

13 years ago

*** This bug has been marked as a duplicate of 102695 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.