Closed Bug 294201 Opened 19 years ago Closed 19 years ago

americanexpress.com -- menus too tall (fill the window)

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: carsten424, Assigned: bc)

References

(
URL
)

Details

(4 keywords)

Attachments

(6 files)

testcase
378 bytes, text/html
Details
Amex page loaded under Firefox 1.6a 2005-11-25 on OS/2
150.39 KB, image/png
Details
Amex page loaded under Firefox 1.6a 2005-11-25 on OS/2 (after login)
60.09 KB, image/png
Details
Amex page loaded under Firefox 1.6a 2005-11-27 on Win32
85.29 KB, image/png
Details
Top of american express login schreen
37.85 KB, image/gif
Details
Middle of amercian express login screen
53.39 KB, image/gif
Details 
The background and info are rendered seperately.
Background is hown on top of page, text below the background.

Build is 20050513.
Btw. the page works with FF 1.0.3..
Summary: Rendering eror on amerricanexpress.com → Rendering eror on americanexpress.com
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
i see no diference in IE and FF1.0.4
no rendering bug!
This can be closed?
(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.
Attached file testcase — 
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.
==> 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
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"
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.
*** Bug 292066 has been marked as a duplicate of this bug. ***
*** Bug 298433 has been marked as a duplicate of this bug. ***
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

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.
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.
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. ***
I just send an email to Amex, let's see what happens.
(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
(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!
Just to clarify, this is also seen in the United States version of the website,
making online bill paying a pain.
*** Bug 308906 has been marked as a duplicate of this bug. ***
*** Bug 308904 has been marked as a duplicate of this bug. ***
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?
(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.
*** Bug 309489 has been marked as a duplicate of this bug. ***
Changing "German" to "English US" per latest comments and duplicates.
Assignee: german → english-us
Component: German → English US
QA Contact: german → english-us
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. ***
*** Bug 310573 has been marked as a duplicate of this bug. ***
*** Bug 311331 has been marked as a duplicate of this bug. ***
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.
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!

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. ***
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
(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.
(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

(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.
(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

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
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
(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
*** Bug 314064 has been marked as a duplicate of this bug. ***
(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 5 describes the root cause.  no more need for speculating.
*** Bug 315015 has been marked as a duplicate of this bug. ***
*** Bug 315251 has been marked as a duplicate of this bug. ***
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!
> 


(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
Please note my comment was not mean spirited.  I am curious just as everyone else subscribed to this post.
Can people with AmEx accounts checkout Bug 315276 and let us know if you can reproduce the problem?
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).

(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
*** Bug 315276 has been marked as a duplicate of this bug. ***
*** Bug 315737 has been marked as a duplicate of this bug. ***
*** Bug 315814 has been marked as a duplicate of this bug. ***
*** Bug 316430 has been marked as a duplicate of this bug. ***
> 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.
Actually, we have an exact testcase for the problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=316738

No JS involved.
(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?
(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
*** Bug 316738 has been marked as a duplicate of this bug. ***
(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.
(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.
Keywords: relnote
*** Bug 317859 has been marked as a duplicate of this bug. ***
Hardware: PC → All
Any chance of someone whipping up some site specific userContent.css changes to work around this?
(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
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

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

(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
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
(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
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.
(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

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.
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.
*** Bug 318766 has been marked as a duplicate of this bug. ***
*** Bug 318764 has been marked as a duplicate of this bug. ***
*** Bug 319363 has been marked as a duplicate of this bug. ***
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; }
}
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.
I believe we have. I don't think they really care.
(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
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.
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.
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.
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.
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.
Yes, you have to restart.
(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
(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
(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 :)
(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.
(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.
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; }
}
(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.
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?
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.
(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.
Yes, its been fixed. I logged into my account and I no longer see this bug. Tried it with a Camino nightly (2005112804).
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?
(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.

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
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>


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).
i went to the site today and it worked fine. sweetness.
As the original reporter I can confirm, that it works mostly now, some buttons still overlay other text and it is fine otherwise.
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 :(
(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
(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.

> 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

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 → ---
(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.
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.
(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.
(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?
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.
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?
www99 is probably the IP name of a load balancer.  there is likely a server in the rotation that has the stale css file.
(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
*** Bug 319451 has been marked as a duplicate of this bug. ***
(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
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.
See attached shot of top half of screen
Middle of login screen. BTW - I'm using Win98SE.
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.
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!
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.
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.
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 
Victor Roberts,

Make sure you are using current drivers for your video card, that appears to be where your problem is.
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.
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.
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.
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.) 
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).
(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
-> 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
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: