253474 - aeepr.com - menu graphics block out text

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: Spanish, defect)

Description

[Marc Bejarano]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

there is a graphical menu at the top right of http://www.aeepr.com/csssave.asp
that is ugly but functional in IE, but blocks text in mozilla.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Chris Lawson (gone)]

Not in Firefox 2 or Camino trunk that I can see...

Comment 2

[Marc Bejarano]

still blocks text for me with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3 ID:2008092414

Comment 3

[Chris Lawson (gone)]

Can you take a screenshot of what you're seeing? This sounds a lot like the "Flash floats on top of content" bug (bug 334321), which isn't TE at all (although their use of Flash for that menu might arguably be evangelizable).

I definitely didn't see this when I made comment 1, which makes me think they've changed something since May.

Comment 4

[Marc Bejarano]

Attachment: screenshot

Comment 5

[Marc Bejarano]

it is flash menu.  i'm not convince i'm seeing bug 334321 because it happens for me in windows, too.

in any  case,  they haven't changed anything on the site in eons.

obviously, they didn't test it in Fx and it looks crappy in Fx, so it is TE :P

Comment 6

[Chris Lawson (gone)]

(In reply to comment #5)
> it is flash menu.  i'm not convince i'm seeing bug 334321 because it happens
> for me in windows, too.

There's nothing in that bug that states it can't happen on Windows, though it didn't happen in Deb's testing in comment 14 (which doesn't mean much, IMO). Furthermore, it's entirely possible there's a Windows-specific bug that I don't know about (since I don't use Windows or Firefox on a regular basis).

Yes, it's clear that they didn't test in Firefox, but that doesn't mean it's TE-worthy. There are lots of sites out there that look like crap in anything other than IE, but unless there's something non-standard being done that specifically breaks Gecko browsers, we're not going to waste our time with it. Since we can't even be sure this is a site bug, and it might be a bug in our browser, making a big stink about their lack of testing is probably not the best idea. If you want to evangelise the site on your own time, fine, but either way, this really isn't something TE should be worrying about, IMO. There are too many high-profile sites broken in much worse ways for us to worry about this.

Comment 7

[Marc Bejarano]

chris: i'm not asking you to spend cycles on this.  i just filed the bug for tracking purposes.  i realize there is no reason to give  this anything but a very low priority with the bigger fish you and others have to fry.

-> trivial

Comment 8

[philippe (part-time)]

That Flash thing (4 images on a white background) is within an absolute positioned div (with left:750px; top 50px). Really nothing to do with bug 334321.

For some obscure reason, they specify a height for the <object> (41px), but not for the embed (it takes the default values of 240px by 200px). And Gecko uses the <embed> while IE uses the <object> in this case.

Comment 9

[RNicoletto]

aeepr.com site have been completely restyled. 
URL provided in comment 0 is no more valid.

Is there any other reproducible way for this bug?

Comment 10

[Chris Lawson (gone)]

Yeah, as far as I can tell, this was FIXED by a site redesign. Marc, if that's not the case, please feel free to reopen and update with appropriate URLs.

Comment 11

[Marc Bejarano]

i agree this TE bug has been fixed :)

re: comment 8, do we think gecko's behavior or IE's behavior is more correct?

Comment 12

[Chris Lawson (gone)]

(In reply to comment #11)
> re: comment 8, do we think gecko's behavior or IE's behavior is more correct?

I'm not sure anyone qualified to make that call is cc'd on this bug, although philippe might be.

Comment 13

[philippe (part-time)]

(In reply to comment #11)
> i agree this TE bug has been fixed :)
> 
> re: comment 8, do we think gecko's behavior or IE's behavior is more correct?

Nobody is wrong. Nobody is 'more correct' in that case. An <embed> element without size (width/height) specified defaults to its intrinsic sizes. And based on what I wrote in comment 8, that page only specified a width/height for the <object> element, which was not used by Gecko.