aeepr.com - menu graphics block out text

RESOLVED FIXED

Status

Tech Evangelism Graveyard
Spanish
--
trivial
RESOLVED FIXED
14 years ago
3 years ago

People

(Reporter: Marc Bejarano, Unassigned)

Tracking

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

10 years ago
Not in Firefox 2 or Camino trunk that I can see...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 2

10 years ago
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 → ---
(Reporter)

Updated

10 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

10 years ago
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.
(Reporter)

Comment 4

10 years ago
Created attachment 341360 [details]
screenshot
(Reporter)

Comment 5

10 years ago
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

10 years ago
(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.
(Reporter)

Comment 7

10 years ago
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

Comment 8

10 years ago
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

8 years ago
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

8 years ago
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
Last Resolved: 10 years ago8 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

8 years ago
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

8 years ago
(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.