Closed
Bug 253474
Opened 21 years ago
Closed 14 years ago
aeepr.com - menu graphics block out text
Categories
(Tech Evangelism Graveyard :: Spanish, defect)
Tech Evangelism Graveyard
Spanish
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bmo, Unassigned)
References
()
Details
Attachments
(1 file)
248.69 KB,
image/png
|
Details |
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•17 years ago
|
||
Not in Firefox 2 or Camino trunk that I can see...
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 2•16 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•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•16 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•16 years ago
|
||
Reporter | ||
Comment 5•16 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•16 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•16 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•16 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•14 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•14 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
Closed: 17 years ago → 14 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 11•14 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•14 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.
![]() |
||
Comment 13•14 years ago
|
||
(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.
Updated•10 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•