Closed
Bug 294201
Opened 20 years ago
Closed 19 years ago
americanexpress.com -- menus too tall (fill the window)
Categories
(Tech Evangelism Graveyard :: English US, defect)
Tech Evangelism Graveyard
English US
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: carsten424, Assigned: bc)
References
()
Details
(4 keywords)
Attachments
(6 files)
The background and info are rendered seperately.
Background is hown on top of page, text below the background.
Build is 20050513.
Summary: Rendering eror on amerricanexpress.com → Rendering eror on americanexpress.com
Comment 2•20 years ago
|
||
Regression Window (using Mozilla Suite Trunk Nightly Builds on Windows XP) for
the URL:
2005012405 Pass
2005012506 Fail
CVS Blame:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-01-24+05%3A00%3A00&maxdate=2005-01-25+06%3A00%3A00&cvsroot=%2Fcvsroot
Given that this regressed on the Trunk over 3 months ago, I'd be surprised if it
is not a dup or possibly an evangelism bug.
Keywords: regression
Summary: Rendering eror on americanexpress.com → Rendering error on americanexpress.com
Comment 3•20 years ago
|
||
i see no diference in IE and FF1.0.4
no rendering bug!
This can be closed?
Comment 4•20 years ago
|
||
(In reply to comment #3)
> i see no diference in IE and FF1.0.4
> no rendering bug!
> This can be closed?
Would be nice to know which version of IE you are running on which version of
Windows, or are you on Mac?
And on which OS did you install Firefox?
The rendering bug is seen on Trunk, meaning you'll see it on Firefox 1.1, if
this bug doesn´t get fixed.
Comment 5•20 years ago
|
||
this testcase demonstrates the change in Mozilla behavior that resulted in the
page layout changing. But the testcase new rendering looks correct.
with current trunk, the inner div's offsetHeight is a bit less than the window
height. older builds report 16. The change seems due to bug 216303, which
made the inner div properly have height: 100%. The page sets the outer div's
height to the offsetHeight of the inner div. The page includes the divs in a
table cell with height=40 so it expects the outer div to be 100% of that =
40px, but the outer div has position:absolute, so that doesn't happen.
Comment 6•20 years ago
|
||
==> Tech Evang
Assignee: general → german
Component: General → German
Keywords: css2
OS: Windows 2000 → All
Product: Mozilla Application Suite → Tech Evangelism
QA Contact: general → german
Summary: Rendering error on americanexpress.com → americanexpress.com -- menus too tall (fill the window)
Version: Trunk → unspecified
Comment 7•20 years ago
|
||
This also affects the UK version of the amex site but doesn't seem to affect the
US version that has a different page layout. Hard to see what to do about this
because they'll probably say something like "we don't support alpha releases of
software, go back to 1.0, this is obviously a bug in their release as it used to
work"
Comment 8•20 years ago
|
||
tell them they were depending on a gecko bug that got fixed, explain what they
were doing wrong and/or point them to my comment in this bug.
telling users to go back to 1.0 for now is not unreasonable (they probably can't
fix it immediately), but it's also reasonable for them to get it fixed. That's
one of the reasons there are alphas -- so people can test with and fix their
stuff that will be broken in the next version.
Comment 9•20 years ago
|
||
*** Bug 292066 has been marked as a duplicate of this bug. ***
Comment 10•20 years ago
|
||
*** Bug 298433 has been marked as a duplicate of this bug. ***
Comment 11•20 years ago
|
||
Just to make the comment that my earlier bug (which was marked as a duplicate -
which would have been clever, since it came first) did include a testcase. I'm
not sure that it woudln't be more use having 292066 open instead of this one?
https://bugzilla.mozilla.org/show_bug.cgi?id=292066
Comment 12•20 years ago
|
||
Chris: this bug also has a testcase and has already been triaged to Tech Evang.
The problem is not a bug in the layout engine, but the website, and this bug
includes analysis that shows that. Duping generally goes to the bug with more
information, which is usually (but not always) the older one.
Comment 13•20 years ago
|
||
Regression range:
Works: 2005-01-24-08
Broken: 2005-01-25-08
Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-01-24+8%3A00&maxdate=2005-01-25+8%3A00&cvsroot=%2Fcvsroot
Suspect: bug 216303
Possibly related: bug 182748, bug 279579
Note that this isn't a real "regression", since the new behavior is correct.
However, it does help to know which bug caused the issue that the site needs to fix.
Comment 14•20 years ago
|
||
Ah, and of course just now I've realized that Andrew Schultz has already came to
the same conclusion. Apologies for the bug spam.
*** Bug 300545 has been marked as a duplicate of this bug. ***
*** Bug 299695 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 17•20 years ago
|
||
I just send an email to Amex, let's see what happens.
Comment 18•20 years ago
|
||
(In reply to comment #17)
> I just send an email to Amex, let's see what happens.
They didn't reply to mine, admittedly the only address I could get was from
their whois entry - couldn't find a thing online.
It's got worse with their latest redesign - it's totally unusable with Firefox.
The tall menus overwrite the data now.
*** Bug 308035 has been marked as a duplicate of this bug. ***
This bug (as www99.americanexpress.com) is a top50 in Reporter.
Keywords: top50
Reporter | ||
Comment 21•19 years ago
|
||
(In reply to comment #18)
> (In reply to comment #17)
> > I just send an email to Amex, let's see what happens.
>
> They didn't reply to mine, admittedly the only address I could get was from
> their whois entry - couldn't find a thing online.
>
> It's got worse with their latest redesign - it's totally unusable with Firefox.
> The tall menus overwrite the data now.
I got an reply, that I emailed to the wrong country!
Comment 22•19 years ago
|
||
Just to clarify, this is also seen in the United States version of the website,
making online bill paying a pain.
Comment 23•19 years ago
|
||
*** Bug 308906 has been marked as a duplicate of this bug. ***
Comment 24•19 years ago
|
||
*** Bug 308904 has been marked as a duplicate of this bug. ***
Comment 25•19 years ago
|
||
The last couple duped bugs are about the United States americanexpress.com
website, I believe. Should this bug be also flagged as U.S. tech evangalism
(can two nations be selected at once?) or should one of those bugs be reopened?
Comment 26•19 years ago
|
||
(In reply to comment #25)
> The last couple duped bugs are about the United States americanexpress.com
> website, I believe. Should this bug be also flagged as U.S. tech evangalism
> (can two nations be selected at once?) or should one of those bugs be reopened?
It happens on the .co.uk site as well.
Comment 27•19 years ago
|
||
*** Bug 309489 has been marked as a duplicate of this bug. ***
Comment 28•19 years ago
|
||
Changing "German" to "English US" per latest comments and duplicates.
Assignee: german → english-us
Component: German → English US
QA Contact: german → english-us
Comment 29•19 years ago
|
||
I sent the following to a customer service agent at americanexpress.com U.S.
site. (They had just helped me with a non-related issue) I think it would help
if a way to correct the website were available here.
>Thank you for your prompt reply. You did not comment on the problem with
>browser rendering:
>>As an aside, I have been browsing with the Firefox 1.5 Beta browser.
>>(available at http://www.mozilla.org/ ) Using that browser, once I sign into
>>americanexpress.com, the web site >doesn't render properly.
>As per this link: https://bugzilla.mozilla.org/show_bug.cgi?id=294201#c5 , the
>problem is due to a bug in the code for the americanexpress.com website (not a
>problem with firefox). Given that Firefox 1.5 will be release to the public in
>about 2-3 months, perhaps this bug in the website can be fixed by then. The
>browser has been downloaded 90 million times in the last year. It
>conservatively makes up 5% of most large websites visitors. That's a lot of
>users that will have a problem in a couple months.
>I hope for a quick solution to this problem. Thanks.
*** Bug 309559 has been marked as a duplicate of this bug. ***
Comment 31•19 years ago
|
||
*** Bug 310573 has been marked as a duplicate of this bug. ***
Comment 32•19 years ago
|
||
*** Bug 311331 has been marked as a duplicate of this bug. ***
Comment 33•19 years ago
|
||
I'm work for Amex, and have noticed this bug whilst using Firefox 1.5.
(But not with IE6/FF1.0)
Is this a browser issue related to change in rendering behavior or is this
**** web-design on our part? If its the latter, is there a quick fix we can
apply to our CSS/HTML to remedy the issue?
If so then I am in a position to expidite this.
I'll be monitoring this bug but can also be reached on chris.v.korhonen@aexp.com.
Comment 34•19 years ago
|
||
Okay, re-reading the thread it looks to be our fault!
I've been playing with our style sheet and pages are looking slightly nicer in
our test environment, thought its not helped by the 'nasty' way we are
generating our Nav menu. Will see what replies come here and then pass the
solution on to the appropriate team.
In response to a few people on the thread, firstly would like to apologise for
any inconvience caused by this- hopefully we can move forward and sort this
thing out! Browser compatibility is something which too be honest we are only
now starting to take seriously - earlier this week we began a small project to
ensure our online applications all work nicely in non-IE browsers, the code we
were using to identify browsers was a bit "not nice" and a relic from the millenium!
This issue affects basically all the markets where the new menu scheme has been
implemented, so US, UK and Germany plus a handful of others. Across both our
static pages and the My Cardmember pages. As the solution is looking like a
simple CSS tweak (once we get our head round the evil Javascript) then should be
resolved for the public release of 1.5.
Odd, I first noticed this about 2 weeks ago, and when I reported it to someone
it was dismissed as I was using a Alpha version of Firefox, so I guess customer
experiences mirror my own!
Comment 35•19 years ago
|
||
I am using 1.5 Beta 2. I submitted a secure message to AmEx about the problem.
Now I run across this bug.
Chris, thanks for trying to get the website fixed. It is rather annoying, but
the site is still functional for me.
*** Bug 312401 has been marked as a duplicate of this bug. ***
Comment 37•19 years ago
|
||
Interestingly enough, the Amex site is unusable in SM 1.1a, though FF 1.0.7
seems to render it correctly (both under OS/2).
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20051014
MultiZilla/1.8.1.0p SeaMonkey/1.1a
Assignee | ||
Comment 38•19 years ago
|
||
(In reply to comment #37)
see comment 5. the bug in question was fixed on the trunk (then 1.8 branch)
after firefox 1.0.x (based on the 1.7 branch) was shipped.
Comment 39•19 years ago
|
||
(In reply to comment #38)
That's quite interesting, because I'm seeing exactly the opposite behavior,
i.e., FF 1.0.7 (shipped before the fix was in the trunk, if I read your comment
correctly, and interpret the statements in comment #5) works, whereas SM 1.1a
(nightly just built this past week) is (still) broken. Did I misread comment #5
and your reference, Bob?
Lewis
Comment 40•19 years ago
|
||
(In reply to comment #39)
> That's quite interesting, because I'm seeing exactly the opposite behavior,
> i.e., FF 1.0.7 (shipped before the fix was in the trunk, if I read your comment
> correctly, and interpret the statements in comment #5) works, whereas SM 1.1a
> (nightly just built this past week) is (still) broken. Did I misread comment #5
> and your reference, Bob?
The bug being fixed is what caused the problem on the Amex site, so your results
make sense.
Comment 41•19 years ago
|
||
(In reply to comment #40)
> The bug being fixed is what caused the problem on the Amex site, so your results
> make sense.
Thanks, Gavin. I wonder if some tweaking of my userchrome.css might work around
the issue in the meantime?
Lewis
Comment 42•19 years ago
|
||
I dont see anything mentioning camino, so I thought I'd point out it seems to
work on OS X w/ Firefox 1.0.6, but not on camino 2005101504
Comment 43•19 years ago
|
||
The problem seems to be in the scripting in https://www99.americanexpress.com/navigation/shared/nav/cbrowser_dom.js
In this script, it sets the height of the <img> tags with ids of cdd_placeholder* to around 500px (in my case). This make everything in the top navigation table be very tall.
Using DomInspector I set the height of these down to 50px and that improved the situation, but I think there may be some other interaction in this script that I can't fix with DomI.
I don't have time at the moment to debug the code because it is formatted so badly in the view-source window, but try looking at why it is coming up with such a large height for those id tags.
Kevin
Comment 44•19 years ago
|
||
This is the #1 issue reported by users in reporter.mozilla.org:
http://reporter.mozilla.org/app/query/?report_description=&report_useragent=&report_gecko=&report_language=&report_platform=&report_oscpu=&report_product=-1&report_file_date_start=YYYY-MM-DD&report_file_date_end=YYYY-MM-DD&show=25&count=on&host_hostname=%25americanexpress%25&report_problem_type=0&report_behind_login=-1&submit_query=Search
Comment 45•19 years ago
|
||
(In reply to comment #43)
> The problem seems to be in the scripting in
> https://www99.americanexpress.com/navigation/shared/nav/cbrowser_dom.js
>
> In this script, it sets the height of the <img> tags with ids of
> cdd_placeholder* to around 500px (in my case). This make everything in the top
> navigation table be very tall.
The problem is the height that is set on the tags with ids "cdd_placeholder?" and "cdd_item?_menu" in this javascript.
I have verified using the Web Developer extension that if you disable javascript after loading the page, and then reload, the page will display properly.
Hopefully that is enough info for the experts on the site to find the problem.
Kevin
Comment 46•19 years ago
|
||
*** Bug 314064 has been marked as a duplicate of this bug. ***
Comment 47•19 years ago
|
||
(In reply to comment #45)
<snip>
> I have verified using the Web Developer extension that if you disable
> javascript after loading the page, and then reload, the page will display
> properly.
>
I can confirm this behavior as well:
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20051021 SeaMonkey/1.1a Mnenhy/0.7.2.0
Of course, disabling JS isn't a workaround, as many features of the site depend upon it, but as you point out, Kevin, this is a good place to start looking for the real culprit.
Lewis
Comment 48•19 years ago
|
||
comment 5 describes the root cause. no more need for speculating.
Comment 49•19 years ago
|
||
*** Bug 315015 has been marked as a duplicate of this bug. ***
Comment 50•19 years ago
|
||
*** Bug 315251 has been marked as a duplicate of this bug. ***
Comment 51•19 years ago
|
||
So Chris Korhonen....
Now that Your company acknowleges the issue, when might we expect the page to be updated so that this issue can be resolved?
(In reply to comment #34)
> Okay, re-reading the thread it looks to be our fault!
>
> I've been playing with our style sheet and pages are looking slightly nicer in
> our test environment, thought its not helped by the 'nasty' way we are
> generating our Nav menu. Will see what replies come here and then pass the
> solution on to the appropriate team.
>
> In response to a few people on the thread, firstly would like to apologise for
> any inconvience caused by this- hopefully we can move forward and sort this
> thing out! Browser compatibility is something which too be honest we are only
> now starting to take seriously - earlier this week we began a small project to
> ensure our online applications all work nicely in non-IE browsers, the code we
> were using to identify browsers was a bit "not nice" and a relic from the millenium!
>
> This issue affects basically all the markets where the new menu scheme has been
> implemented, so US, UK and Germany plus a handful of others. Across both our
> static pages and the My Cardmember pages. As the solution is looking like a
> simple CSS tweak (once we get our head round the evil Javascript) then should be
> resolved for the public release of 1.5.
>
> Odd, I first noticed this about 2 weeks ago, and when I reported it to someone
> it was dismissed as I was using a Alpha version of Firefox, so I guess customer
> experiences mirror my own!
>
Assignee | ||
Comment 52•19 years ago
|
||
(In reply to comment #51)
They are working on it and it will be ready when it is ready. Please don't be mean spirited. Also, there is no need to quote entire comments in bugs.
Assignee: english-us → bob
Comment 53•19 years ago
|
||
Please note my comment was not mean spirited. I am curious just as everyone else subscribed to this post.
Assignee | ||
Comment 54•19 years ago
|
||
Can people with AmEx accounts checkout Bug 315276 and let us know if you can reproduce the problem?
Comment 55•19 years ago
|
||
I've checked and I think the poster is refering to the same bug. The information does seem to vanish, but in actual fact it's just pushed way down the page. The poster probably didn't notice the scroll bar.
In reference to Dave above, I think asking 'when' is certainly not premature. This bug has been around since at least April of 2005 when Amex did their redesign (https://bugzilla.mozilla.org/show_bug.cgi?id=292066).
Comment 56•19 years ago
|
||
(In reply to comment #54)
> Can people with AmEx accounts checkout Bug 315276 and let us know if you can
> reproduce the problem?
>
I think this is the same issue, per Chris' comment #55.
BTW, I see this when logging in through the small business dashboard. I think the regular Amex login may be fixed (at least partially). The url for the small business dashboard login is http://home3.americanexpress.com/smallbusiness/Landing/smallbusinessdashboard.asp?aexp_nav=dashboard, and that page is a complete mess, as described in this bug.
Lewis
Comment 57•19 years ago
|
||
*** Bug 315276 has been marked as a duplicate of this bug. ***
*** Bug 315737 has been marked as a duplicate of this bug. ***
Comment 59•19 years ago
|
||
*** Bug 315814 has been marked as a duplicate of this bug. ***
Comment 60•19 years ago
|
||
*** Bug 316430 has been marked as a duplicate of this bug. ***
Comment 61•19 years ago
|
||
> BTW, I see this when logging in through the small business dashboard. I think
> the regular Amex login may be fixed (at least partially). The url for the small
> business dashboard login is
>
> Lewis
The AmEx login page has never been the problem. It is the pages after the loging and they are still frustratingly not diplaying normally.
Comment 62•19 years ago
|
||
Actually, we have an exact testcase for the problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=316738
No JS involved.
Comment 63•19 years ago
|
||
(In reply to comment #62)
> Actually, we have an exact testcase for the problem:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=316738
>
> No JS involved.
That's essentially the same testcase that's already attached to this bug, no?
Comment 64•19 years ago
|
||
(In reply to comment #61)
> > BTW, I see this when logging in through the small business dashboard. I think
> > the regular Amex login may be fixed (at least partially). The url for the small
> > business dashboard login is
>
> The AmEx login page has never been the problem. It is the pages after the
> loging and they are still frustratingly not diplaying normally.
>
Please note the link in my comment #56. That is the page where I normally log in. There are other pages where login is available, and these are the ones being discussed in this bug. So, perhaps the page where you are logging in does not exhibit the behavior, but some others do. The point is that several pages on that site (with and without login dialogs) do not display properly.
Apologies to everyone for the bugspam.
Lewis
Comment 65•19 years ago
|
||
*** Bug 316738 has been marked as a duplicate of this bug. ***
Comment 66•19 years ago
|
||
(In reply to comment #47)
> (In reply to comment #45)
>
> <snip>
>
> > I have verified using the Web Developer extension that if you disable
> > javascript after loading the page, and then reload, the page will display
> > properly.
> >
> I can confirm this behavior as well:
>
> Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20051021 SeaMonkey/1.1a
> Mnenhy/0.7.2.0
>
> Of course, disabling JS isn't a workaround, as many features of the site depend
> upon it, but as you point out, Kevin, this is a good place to start looking for
> the real culprit.
>
> Lewis
>
I just spoke with Amex and they were no help. However, to add to what you have already discovered, I use the site regularly and the problem came with their redesign in Sept late. I noticed that changing the firefox setting of view/page style to no style and then back again causes the page to re-align with a smaller px. It's not a total fix though because some of the menus are now in front of some of the data.
Comment 67•19 years ago
|
||
(In reply to comment #66)
> (In reply to comment #47)
> > (In reply to comment #45)
> >
> > <snip>
> >
> > > I have verified using the Web Developer extension that if you disable
> > > javascript after loading the page, and then reload, the page will display
> > > properly.
> > >
> > I can confirm this behavior as well:
> >
> > Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20051021 SeaMonkey/1.1a
> > Mnenhy/0.7.2.0
> >
> > Of course, disabling JS isn't a workaround, as many features of the site depend
> > upon it, but as you point out, Kevin, this is a good place to start looking for
> > the real culprit.
> >
> > Lewis
> >
> I just spoke with Amex and they were no help. However, to add to what you have
> already discovered, I use the site regularly and the problem came with their
> redesign in Sept late. I noticed that changing the firefox setting of
> view/page style to no style and then back again causes the page to re-align
> with a smaller px. It's not a total fix though because some of the menus are
> now in front of some of the data.
>
One other point I almost forgot. The pages view perfectly right up until the very end of the page load. Then the top portion expands about two screens and forces the bottom portion, which in itself is fine, to the bottom.
Comment 68•19 years ago
|
||
*** Bug 317859 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Hardware: PC → All
Comment 69•19 years ago
|
||
Any chance of someone whipping up some site specific userContent.css changes to work around this?
Comment 70•19 years ago
|
||
(In reply to comment #69)
> Any chance of someone whipping up some site specific userContent.css changes to
> work around this?
>
I'm attempting to do that now, but without much success (probably due to my lack of experience with css). Anyway, I'm going to take what I have over to n.p.m.browser and see if anyone can help tighten things up (as I don't want to generate more bug spam here than necessary). So far, I'm using the @-moz-document rule implemented by David Baron (see http://lists.w3.org/Archives/Public/www-style/2004Aug/0135.html/):
@-moz-document url(http://www133.americanexpress.com/osbn/landing/manageyouraccount.asp) {
.cdd0_main_menu{
height:10% !important;
}
}
(NB: The absolute url I'm using is just the one where I log in. Once I test this out and get it working, I'll broaden my scope to help fit other folks' Amex pages, too.)
Lewis
Comment 71•19 years ago
|
||
First hack at userContent.css:
/* Hack to make Amex pages readable in SeaMonkey */
@-moz-document domain(americanexpress.com)
{
.cdd0_main_menu{
height:1.1em !important;
}
.cdd1_main_menu{
height:1.1em !important;
}
.cdd2_main_menu{
height:1.1em !important;
}
.cdd3_main_menu{
height:1.1em !important;
}
}
Please try this on your favorite Amex pages and let me know how it works.
Lewis
Comment 72•19 years ago
|
||
Didn't seem to fix things for me, although it was better than before:
http://chris.polymathic.net/chris/ff_amex1.png
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051127 Firefox/1.6a1
Comment 73•19 years ago
|
||
(In reply to comment #72)
> Didn't seem to fix things for me, although it was better than before:
> http://chris.polymathic.net/chris/ff_amex1.png
>
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051127
> Firefox/1.6a1
>
Thanks, Chris. Could you post an attachment as to what it looks like for you without the css override? On SeaMonkey 1.5a (and aparently Camino, though I'm not sure of the reporter's build), the menu row is almost right, with some extra whitespace underneath.
Lewis
Comment 74•19 years ago
|
||
Updated•19 years ago
|
Attachment #204355 -
Attachment description: Amex page loaded under Firefox 1.6a 2005-11-27 on OS/2 → Amex page loaded under Firefox 1.6a 2005-11-25 on OS/2
Comment 75•19 years ago
|
||
Comment 76•19 years ago
|
||
Comment 77•19 years ago
|
||
(In reply to comment #72)
> Didn't seem to fix things for me, although it was better than before:
> http://chris.polymathic.net/chris/ff_amex1.png
>
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051127
> Firefox/1.6a1
>
Chris, not the attachments I've posted. The first two were taken with the November 25 nightly of Firefox 1.6a for OS/2 (latest available "official" nightly), and the last was with the same Firefox build as yours, under Windows 2000 Advanced Server.
Are you sure that you added the css lines userContent.css in the chrome directory of the profile you used to access the page?
Lewis
Comment 78•19 years ago
|
||
Looks perfect now in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 with Chris's userContent.css hack.
Comment 79•19 years ago
|
||
(In reply to comment #78)
> Looks perfect now in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8)
> Gecko/20051111 Firefox/1.5 with Chris's userContent.css hack.
>
Thanks for reporting, John. Actually, it's my hack, but I'm just as happy that it works, no matter who gets the credit! ;-)
Lewis
Comment 80•19 years ago
|
||
Problem continues to exist on 11/30 with the follow version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Menus are too tall. Also, extended display rewriting for account activity page once logged in.
Comment 81•19 years ago
|
||
Since AmEx still needs to fix this page, here is how to send them feedback. (They apparently don't post an e-mail address.) To send bug reports to AmEx - log in to your account - scroll down to bottom and click on crosshair in lower right corner. Rate appropriately. I suggest leaving a message with a link to this bug to which AmEx coders can refer.
Comment 82•19 years ago
|
||
*** Bug 318766 has been marked as a duplicate of this bug. ***
Comment 83•19 years ago
|
||
*** Bug 318764 has been marked as a duplicate of this bug. ***
Comment 84•19 years ago
|
||
*** Bug 319363 has been marked as a duplicate of this bug. ***
Comment 85•19 years ago
|
||
They recently changed their pages so that the old hack doesn't work anymore. Here is what works now (in userContent.css):
/* Hack to make Amex pages readable in SeaMonkey */
@-moz-document domain(americanexpress.com)
{
.cdd0_main_menu,cdd1_main_menu,.cdd2_main_menu,.cdd3_main_menu,
.cdd1_main_items { height:1em !important; }
}
Assignee | ||
Comment 86•19 years ago
|
||
Everyone who has an account with Amercian Express should make sure to complain to them about this so that they realize the magnitude of the issue and raise its priority.
Comment 87•19 years ago
|
||
I believe we have. I don't think they really care.
Comment 88•19 years ago
|
||
(In reply to comment #85)
> They recently changed their pages so that the old hack doesn't work anymore.
> Here is what works now (in userContent.css):
>
My former hack still works for me (using the OPEN Small Business pages - http://www133.americanexpress.com/osbn/landing/manageyouraccount.asp et seq).
I haven't tried your latest go at this, but I will. I'm curious to see if it eliminates the last vestige of white space beneath several of the menu items.
Lewis
Comment 89•19 years ago
|
||
In Firefox 1.5 alone (includes 1.5 RC's), we have over 1100 reports from Firefox users about AmEx alone:
http://reporter.mozilla.org/app/query/?show=25&count=on&report_product=Firefox%2F1.5&submit_query=Search
May want to put that in any notes. It's not an isolated case of a few users. They are the #1 reported website.
Comment 90•19 years ago
|
||
That's just for the www99 subdomain. If you add up all the Amex reports, it's more like 1,664. Some people from Mozilla need to contact them directly if at all possible.
Comment 91•19 years ago
|
||
Well, I contacted them by telephone as someone "involved with the development of the Firefox browser." I was able to get as far as someone's voicemail who seemed to be a director of technical content or something like that. We'll see.
Comment 92•19 years ago
|
||
Ok. This addresses every element in their CSS file that has a 100% height set:
{
.cdd0_main_menu,.cdd0_main_items,.cdd0_main_items_rollover,.opera0_main_items_rollover,.cdd0_sub_menu,
.cdd1_main_menu,.cdd1_main_items,.cdd1_main_items_rollover, .opera1_main_items_rollover,.cdd1_sub_menu,
.cdd2_main_menu,.cdd3_main_menu,.cdd4_main_items_rollover { height:auto !important; }
}
The auto height makes it look exactly perfect here.
Comment 93•19 years ago
|
||
is a firefox restart required after editing userContent.css?
i tried editing mine using the chromEdit extension with the hack from comment #85 and it still looks messed up to me. also tried the other two tweaks from comment #71 and comment #92 without a restart and things weren't fixed.
amex's technology help desk seems to be the right place to complain: 800-297-7500 option 0
supposedly, a business analyst will look into this and the person i spoke with will update me.
Comment 94•19 years ago
|
||
Yes, you have to restart.
Comment 95•19 years ago
|
||
(In reply to comment #93)
> is a firefox restart required after editing userContent.css?
You can also use the stylish extension to add this rule and not have to do a restart
See http://forums.mozillazine.org/viewtopic.php?t=327735
the extension just requires a reload in order to take effect.
Kevin
Comment 96•19 years ago
|
||
(In reply to comment #92)
> Ok. This addresses every element in their CSS file that has a 100% height set:
>
<snip>
> The auto height makes it look exactly perfect here.
>
Yes, Jerry, that does indeed look just great; much nicer than my original. Thanks for the good work!!
Lewis
Comment 97•19 years ago
|
||
(In reply to comment #95)
> You can also use the stylish extension to add this rule and not have to do a
> restart
thanks, kevin! for some reason, my changes to userContent.css never had any effect, but stylish worked perfectly. the fact that changes are effective with just a page reload is a bonus :)
Comment 98•19 years ago
|
||
(In reply to comment #92)
> Ok. This addresses every element in their CSS file that has a 100% height set:
>
Thanks to both Lewis and Jerry, this works perfectly.
I've contacted Amex in Australia and the only suggestion they could offer was to email technology.group.counsel@aexp.com - which I've done, but not yet received a reply.
Comment 99•19 years ago
|
||
(In reply to comment #92 from Jerry Baker)
> Ok. This addresses every element in their CSS file that has a 100% height set:
>
> The auto height makes it look exactly perfect here.
>
I couldn't get the Styler extention to install so I tried this and it works great.
Thanks Lewis and Jerry! and thanks to David Baron for implementing this extension (see
http://lists.w3.org/Archives/Public/www-style/2004Aug/0135.html/).
So new folks don't have to follow all the threads back to try and figure this out. Here is the complete instructions on how to make this hack work:
Create the following in a text editor and save it to your profile\chrome folder as "userContent.css".
-------
/* Hack to make Amex pages readable */
@-moz-document domain(americanexpress.com)
{
.cdd0_main_menu,.cdd0_main_items,.cdd0_main_items_rollover,.opera0_main_items_rollover,.cdd0_sub_menu,
.cdd1_main_menu,.cdd1_main_items,.cdd1_main_items_rollover,
.opera1_main_items_rollover,.cdd1_sub_menu,
.cdd2_main_menu,.cdd3_main_menu,.cdd4_main_items_rollover { height:auto
!important; }
}
-------
You can locate your profile:
for Mozilla/Seamonkey - http://www.mozilla.org/start/1.5/faq/profile.html#location
for Firefox: - http://www.mozilla.org/support/firefox/edit
Now if AmEx would just update their pages then everyone could move on.
Thanks to everyone for their efforts here.
Comment 100•19 years ago
|
||
I just tested this out with Firefox (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5)
Works Great! Good job!
usercontent.css
/* Hack to make Amex pages readable */
@-moz-document domain(americanexpress.com)
{
.cdd0_main_menu,.cdd0_main_items,.cdd0_main_items_rollover,.opera0_main_items_rollover,.cdd0_sub_menu,
.cdd1_main_menu,.cdd1_main_items,.cdd1_main_items_rollover,
.opera1_main_items_rollover,.cdd1_sub_menu,
.cdd2_main_menu,.cdd3_main_menu,.cdd4_main_items_rollover { height:auto
!important; }
}
Comment 101•19 years ago
|
||
(In reply to comment #93)
> amex's technology help desk seems to be the right place to complain:
> 800-297-7500 option 0
>
> supposedly, a business analyst will look into this and the person i spoke with
> will update me.
that person's email bounces and i haven't been able to reach her since. i did just speak with a ms. jordon at the same phone number and she says her group is definitely responsible for fixing this, is aware of the problem, but has no ETA. she was quite difficult on the phone and i asked her if it may help if all the rest of amex's customers who are affected by this were to call to let them know this is something they need to fix quickly and she said that would be fine.
i reccomend that all US amex cardholders on this bug call that number and log a complaint. hopefully, it'll light a fire under somebody.
Comment 102•19 years ago
|
||
It looks to me like this has been fixed... I haven't changed anything at my end or put any of the workarounds in place, and this morning the long menus are gone, at least on the Small Business section on www99. Anyone else seeing it working better now?
Comment 103•19 years ago
|
||
It appears that they have removed the 100% height from most of the affected elements. The server claims this was done at 03:13 GMT.
Comment 104•19 years ago
|
||
(In reply to comment #102)
> It looks to me like this has been fixed... I haven't changed anything at my
> end or put any of the workarounds in place, and this morning the long menus are
> gone, at least on the Small Business section on www99. Anyone else seeing it
> working better now?
Yes, it is working well for me in the Personal Cards section of www99 on FF 1.5, and having never applied nay of the workarounds.
Comment 105•19 years ago
|
||
Yes, its been fixed. I logged into my account and I no longer see this bug. Tried it with a Camino nightly (2005112804).
Comment 106•19 years ago
|
||
This looks good to me on a page that didn't used to look right. Has anyone come across pages that are still broken since the fix was applied?
Comment 107•19 years ago
|
||
(In reply to comment #106)
> This looks good to me on a page that didn't used to look right. Has anyone come
> across pages that are still broken since the fix was applied?
>
Using Firefox 1.5 on the Amex site today, I find that every page available to me now displays correctly. This was not the case before with the Recent Activity page, so I believe the bug is squashed when it comes to Amex.
Comment 108•19 years ago
|
||
This wa a problem for me but now all appears good! Time to squash this bug
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 109•19 years ago
|
||
most appear to be fixed. Looking at the 29 links from the above url the following still cause me problems:
http://www.americanexpress.com/germany/tcc/index.html
http://www.americanexpress.com/germany/tc/index.html
http://www.americanexpressofferzone.com/selects/HomePage.aspx?cntry=DE&lang=DE&acct=prop
So there are probably some pages still left. If anyone has more time to scan the site using Spider and list problematic urls here that would be nice.
See <http://bclary.com/2004/07/10/mozilla-spiders>
Comment 110•19 years ago
|
||
The easiest way to do this would probably be to spider the domains for CSS files and then look for 100% height on elements that shouldn't be that (almost all).
Comment 111•19 years ago
|
||
i went to the site today and it worked fine. sweetness.
Reporter | ||
Comment 112•19 years ago
|
||
As the original reporter I can confirm, that it works mostly now, some buttons still overlay other text and it is fine otherwise.
Comment 113•19 years ago
|
||
This morning I logged in, and to my horror, it's regressed again. Someone at Amex can't seem to make up their minds about whether or not this should be fixed properly :(
Comment 114•19 years ago
|
||
(In reply to comment #113)
> This morning I logged in, and to my horror, it's regressed again. Someone at
> Amex can't seem to make up their minds about whether or not this should be
> fixed properly :(
>
Hmm.... odd. The global css/js components have been modified so for the most part this issue should have been fixed - can you post the exact URL of any affected pages so that they can be investigated further?
Cheers
Comment 115•19 years ago
|
||
(In reply to comment #114)
> Hmm.... odd. The global css/js components have been modified so for the most
> part this issue should have been fixed - can you post the exact URL of any
> affected pages so that they can be investigated further?
I'm sorry, it turns out it might have been Firefox being silly. It seems to have somehow put an older copy of the CSS in cache and used that (even though a couple of days ago it was using the new, correct one). A shift-reload fixed it. Sorry for the bug spew.
Comment 116•19 years ago
|
||
> I'm sorry, it turns out it might have been Firefox being silly. It seems to
> have somehow put an older copy of the CSS in cache and used that (even though a
> couple of days ago it was using the new, correct one). A shift-reload fixed
> it. Sorry for the bug spew.
No worries.
As i said, the global components have been updated to resolve this issue, however there may still be some 'rogue pages' which are using a copy of the component or otherwise which may still be affected (like americanexpressofferzone.com). In this case, please post the URL here and these can be fixed.
Cheers
Comment 117•19 years ago
|
||
They broke it again. The nav_menu_styles.css has reverted to a version from June 1 of this year. Is there anyone at americanexpress reading this bug? Please fix this once and for all.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 118•19 years ago
|
||
(In reply to comment #117)
> They broke it again. The nav_menu_styles.css has reverted to a version from
> June 1 of this year. Is there anyone at americanexpress reading this bug?
> Please fix this once and for all.
>
I've just checked a few pages (US and UK homepage) and it appears fine. Can you confirm the URL of the affected page(s) so that we can investigate this further, also may be worth ensuring that your browser isnt using a cached version of the css file.
Comment 119•19 years ago
|
||
It's the www99 server. https://www99.americanexpress.com/navigation/shared/nav/nav_menu_styles.css
Comment 120•19 years ago
|
||
LOL. Now it's replaced with a version from 12-08-2005. Are you sure there isn't a server farm at Amex with some bad copies of this CSS file? I don't keep a disk cache, so to have it fail 10 minutes ago means it came from the server that way.
Comment 121•19 years ago
|
||
(In reply to comment #119)
> It's the www99 server.
> https://www99.americanexpress.com/navigation/shared/nav/nav_menu_styles.css
Looking at the file, or at least the version I can see, it was last modified on Dec 9th and is consistant with the fixed version.
Comment 122•19 years ago
|
||
(In reply to comment #120)
> LOL. Now it's replaced with a version from 12-08-2005. Are you sure there isn't
> a server farm at Amex with some bad copies of this CSS file? I don't keep a
> disk cache, so to have it fail 10 minutes ago means it came from the server
> that way.
>
Now thats a tad weird. I'm still being served the Dec 9th version... and even though I'm in Europe, it should be coming from the same server farm...
Just out of curiosity, where are you in the world and what browser are you using?
Comment 123•19 years ago
|
||
I am in Los Angeles using FF 20051218.
Here's the deal. It worked for me on 12-09 as I am the one who reported here that it was fixed. It has worked ever since. Today, when I logged in the problem returned. The last-modified date on the CSS file was 6-01-2005. I do not have a disk cache, and I am not behind a proxy. That means every time I close my browser, everything is gone. When I go back to Americanexpress.com, the pages have to come from the server. There is definitely something funky going on.
Comment 124•19 years ago
|
||
From the sounds of it its probably just a temporary issue, either with the server farm or something somewhere in between.
I'll take a quick look at my work inbox to see if there are any outages or things going on, if this a problem on our end then I would expect it sorted within the next day or so.
Anyone else experiencing similar problems?
Comment 125•19 years ago
|
||
www99 is probably the IP name of a load balancer. there is likely a server in the rotation that has the stale css file.
Comment 126•19 years ago
|
||
(In reply to comment #125)
> www99 is probably the IP name of a load balancer. there is likely a server in
> the rotation that has the stale css file.
>
I tend to agree, Marc. Novell iChain (http://www.novell.com/products/ichain/) will work like this (the iChain server sits in front of the server farm and dynamically balances the load), and although I don't know for a fact that they are using Novell's product, it stands to reason that they would be using something similar, considering the sheer size of their client base. While in theory all servers should be pulling the same data from a shared location, it's entirely possible that there are several (local) storage pools from which groups of them pull, and just as likely that they don't all sync at the same time (imagine the load that would produce).
As we're only a few days away form the correction to the css, I would hold back rushing to judgment until after the first of the year. Sorry for the bug spam, everyone, and let's just sit tight for a few more days to see how this all shakes out.
Lewis
Comment 127•19 years ago
|
||
*** Bug 319451 has been marked as a duplicate of this bug. ***
Comment 128•19 years ago
|
||
Similar problem (I think) at https://www.americanexpress.com/homepage/open_cm.shtml?openvan=open
Comment 129•19 years ago
|
||
(In reply to comment #128)
> Similar problem (I think) at
> https://www.americanexpress.com/homepage/open_cm.shtml?openvan=open
>
Looks fine from here this morning (all hacks commented out of userContent.css).
Lewis
Comment 130•19 years ago
|
||
Vic: Can you provide a screenshot of the behavior you're seeing? I'm not seeing problems when I go to the link you provided.
Comment 131•19 years ago
|
||
See attached shot of top half of screen
Comment 132•19 years ago
|
||
Middle of login screen. BTW - I'm using Win98SE.
Comment 133•19 years ago
|
||
It looks like the situation Vic is having is specific to when you set Windows to use Extra Large system font sizes. I was able to recreate the issue on XP using Extra Large fonts. Both normal and large font sizes work without issue.
Comment 134•19 years ago
|
||
Win98SE does not have Extra Large Fonts, but I am using Large Fonts on this machine. I have another Win98SE system with Firefox 1.5 that us set for Small Fonts. I will test that and get back to you.
Thanks!
Comment 135•19 years ago
|
||
Well, we have a problem. The second Win98SE machine using the same version of Firefox renders this page correctly with both Small and Large fonts. Now, I'm really confised. Will change the first machine to Small fonts and try again.
Comment 136•19 years ago
|
||
Now I can't even reproduce my own problem!
I set the first machine to Small fonts and the problem went away. However, it is also gone when I switch back to Large fonts! Earlier today I had this problem when I opened the subject page multiple times, as shown by the screen shots.
The second machine was set to 16-bit color while the first machine, the one with the problem was set to 24-bit color. So, I set the frist machine to 16-but color to see if that would fix the proble, and it did. But when I returned to Large Fonts and 24-bit color, the same settings I had before, the problem is still gone!
I may have previously adjusted the font size for individual items, and these settings may have been reset to the defaults when I switched to Small Fonts. However, all I know is that now I am back to Large Fonts and 24-bit color and all is well at this wab site.
But - the fact that someone else could replicate the problem using Extra Large Fonts on Windows XP indicates that there is some type of problem.
Comment 137•19 years ago
|
||
Well, it's back - and now crashes Firefox with the following error message:
FIREFOX caused a general protection fault
in module ATI2DRAB.DRV at 0007:000031c4.
Registers:
EAX=00000000 CS=0347 EIP=000031c4 EFLGS=00010206
EBX=001ba800 SS=663f ESP=db3bc40a EBP=00006600
ECX=00006600 DS=0cf7 ESI=00000000 FS=0000
EDX=003f6a00 ES=03cf EDI=00000000 GS=0000
Bytes at CS:EIP:
ff d3 1f 5e 58 c3 83 c1 3f 83 e1 c0 3b 4e 1c 7f
Stack dump:
015f0cf7 00000000 00000000 0000302b 003f6a00 00006600 567e0000 00002da4 00002d2b 00000000 0000567e 000003cf 0000c4a2 0000cd72 567e0657 0000c46c
Comment 138•19 years ago
|
||
Victor Roberts,
Make sure you are using current drivers for your video card, that appears to be where your problem is.
Comment 139•19 years ago
|
||
Thanks. I noticed that the driver identified was for my video card after I posted my last response. Mozilla 1.5 is the first program that had any problem with this video card. I just updated the drivers and so far all is OK. Time will tell.
Comment 140•19 years ago
|
||
When I clicked that link this morning, it was too tall just like when I reported this reopened. Shift+reload fixed it. It's weird how this keeps happening.
Comment 141•19 years ago
|
||
Clicking on the Reload button now breaks the page. Those testing should note that the page appears to load correctly at first, and then some code is loaded that creates that suddenly makes the section right below the top far too tall. This is still using Large Fonts with 24-bit color and the updated driver.
Comment 142•19 years ago
|
||
The problem with americanexpress.com is not limited to Large Fonts. After switching to Small Fonts, the page will be rendered incorrectly about 10% of the time when I click on the Refresh button.
I also notice that 1.5 is rather unstable compared to earlier versions of Firefox. On the support contact page of amazon.com if I scroll down the page with the wheel on my mouse the page will jump back to the top as soon as I move the mouse. (I know this is for another problem report.)
Comment 143•19 years ago
|
||
I can verify that. Issuing 60 HEAD requests to https://www99.americanexpress.com/navigation/shared/nav/nav_menu_styles.css results in 7 that are the old, broken CSS (Last-Modified June-01-05).
Comment 144•19 years ago
|
||
(In reply to comment #143)
> I can verify that. Issuing 60 HEAD requests to
> https://www99.americanexpress.com/navigation/shared/nav/nav_menu_styles.css
> results in 7 that are the old, broken CSS (Last-Modified June-01-05).
>
Jerry, this is precisely what we discussed in comment #125 and comment #126. I guess the question, then, is how long Amex's server(s) and/or forward proxy/proxies will take to update its/their cache with the correct code. Meanwhile, the hack you refined still works, and will ensure that the pages look as they should.
In the meantime, could someone please re-close this bug, as it's not our issue (bug), and the workaround we had in place before is still valid while Amex fixes their broken code in all their caches?
Lewis
Comment 145•19 years ago
|
||
-> fixed. They have fixed the code, now they have a proxy issue. That's not evangelism, and so is out of the realm of bugzilla.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
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
•