Closed Bug 253474 Opened 15 years ago Closed 9 years ago

aeepr.com - menu graphics block out text

Categories

(Tech Evangelism Graveyard :: Spanish, defect, trivial)

defect
Not set
trivial

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bmo, Unassigned)

References

()

Details

Attachments

(1 file)

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:
Not in Firefox 2 or Camino trunk that I can see...
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
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
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Attached image screenshot
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
(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.
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
Severity: normal → trivial
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.
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?
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.
Status: NEW → RESOLVED
Closed: 12 years ago9 years ago
Resolution: --- → FIXED
i agree this TE bug has been fixed :)

re: comment 8, do we think gecko's behavior or IE's behavior is more correct?
(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.
(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.
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.