Closed Bug 403868 Opened 17 years ago Closed 17 years ago

[FIX]Some menus on Amazon.com don't work

Categories

(Core :: General, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9beta2

People

(Reporter: andrewm715+bugzilla, Assigned: bzbarsky)

References

()

Details

(Keywords: regression, testcase, top100)

Attachments

(5 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007111404 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007111404 Minefield/3.0b2pre

Some menus on Amazon.com no longer display, instead they show "-- CONTENT GOES HERE (simple)--". The menus display fine on Firefox 2.0.0.9, but are broken in the latest trunk nightly.

I tried two earlier builds going back to 20071101_1016 but it was broken in both of them.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.amazon.com/
2. Mouse over one of these three menus (the drop-down arrows, not the text): "Today's Deals", "Gifts & Wish Lists" or "Gift Certificates"
Actual Results:  
See -- CONTENT GOES HERE (simple)--. Where's the menu?

Expected Results:  
See the proper menus, like in Firefox 2.0.0.9.
Flags: blocking1.9?
Keywords: regression
Version: unspecified → Trunk
FWIW, changing the UA string didn't make it work...
Keywords: qawanted, top100
OS: Windows Vista → All
Hardware: PC → All
I don't see any JS errors but I see tons of warnings like:

Warning: reference to undefined property tmpArray[i]
Source File: http://z-ecx.images-amazon.com/images/G/01/nav2/gamma/n2CoreLibs/n2CoreLibs-utilities-12468.js
Line: 1532
Tested on WinXP.

Confirming bug in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101605 Minefield/3.0a9pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7) Gecko/2007080210 GranParadiso/3.0a7
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061202 Minefield/3.0a1

Page works correctly in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10pre) Gecko/20071115 BonEcho/2.0.0.10pre
Safari 3.0.3 (522.15.5)

Menu disabled in:
Opera/9.24 (Windows NT 5.1; U; en)
(In reply to comment #5)
> Tested on WinXP.
> 
> Confirming bug in:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101605
> Minefield/3.0a9pre
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7) Gecko/2007080210
> GranParadiso/3.0a7
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061202
> Minefield/3.0a1
> 
> Page works correctly in:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10pre) Gecko/20071115
> BonEcho/2.0.0.10pre
> Safari 3.0.3 (522.15.5)
> 
> Menu disabled in:
> Opera/9.24 (Windows NT 5.1; U; en)

I should add just for completeness that it works correctly in:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)

(In reply to comment #6)
> How about that, this changed two years ago on this date.
> 
> 20051114 works
> 20051115 broke
> 
> 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-11-14+04%3A00%3A00&maxdate=2005-11-15+07%3A00%3A00&cvsroot=%2Fcvsroot
> 
> Nothing jumps out to me.

Thanks for finding the regression window so fast.

I'm wondering, since it's been two whole years since the regression and given that Opera doesn't display the menus correctly (and Opera is usually pretty good when it comes to standards compliance), perhaps this is a Tech Evangelism issue rather than a bug in Gecko? (I'm a relative newb so I can't tell from looking at the web page markup/JavaScript whether it's valid or not.)
That's why I haven't confirmed the bug.  I don't know what the problem is.  And therefore if the problem is the browser or the site.  
+'ing and making it a P2 since this breaks a top site.  Any help here appreciated.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Opera is not broken, it just shows a simpler version of the page without the pop-over menu.  I don't know if Amazon is doing browser detection or object detection.

In the regression window, Bug 315770 looks tasty.
"people really should not be depending on things if more than one node in the document has the same id..."

-  // If aForce is true, the new content will become the new content
-  // returned for this ID, even if there is already such content.
-  PRBool AddIdContent(nsIContent* aContent, PRBool aForce);
+  PRBool AddIdContent(nsIContent* aContent);                   

	

                                                                                

                                                                                
I'll be posting a minimized testcase very soon.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file testcase
(In reply to comment #10)
> In the regression window, Bug 315770 looks tasty.
> "people really should not be depending on things if more than one node in the
> document has the same id..."
> 
> -  // If aForce is true, the new content will become the new content
> -  // returned for this ID, even if there is already such content.
> -  PRBool AddIdContent(nsIContent* aContent, PRBool aForce);
> +  PRBool AddIdContent(nsIContent* aContent);                   

The Amazon page does indeed have two objects with the same ID (dynamically added via JS), and they do depend on us to return the newer one.  (which we don't anymore, as shown by the above code snippet from Bug 315770's patch.

IMHO, this is Amazon's bad.  Do we need to restore our old behavior...?  Maybe we should just notify them of their bug instead.  Boris, what do you think?
Opera, Konqueror, and IE apparently all show "success" on that testcase.  We should probably just back out bug 315770...

Gods I hate the web.  :(
Blocks: 315770
Couldn't we simply return the first one if there are multiple elements with the same ID? The comparePosition implementation is pretty fast.
Hmm.  We probably could, yes.  Is that what the other UAs do, basically?
OK.  That's what Opera and Konqueror do, for sure.  It's what we do if the HTML is just static.  Let's do it.
Attached patch FixSplinter Review
I still need to write tests for this (inserting both before and after, with table live and not, etc, etc).  Will do that tomorrow, I hope.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #289616 - Flags: superreview?(jonas)
Attachment #289616 - Flags: review?(jonas)
Summary: Some menus on Amazon.com no longer work → [FIX]Some menus on Amazon.com no longer work
Target Milestone: --- → mozilla1.9 M10
Comment on attachment 289616 [details] [diff] [review]
Fix

sold!
Attachment #289616 - Flags: superreview?(jonas)
Attachment #289616 - Flags: superreview+
Attachment #289616 - Flags: review?(jonas)
Attachment #289616 - Flags: review+
Keywords: qawantedtestcase
Minor summary correction, as they have never worked since the recent site redesign.
Summary: [FIX]Some menus on Amazon.com no longer work → [FIX]Some menus on Amazon.com don't work
Attached patch TestsSplinter Review
Would it really kill us to have only one getElementById implementation instead of 3?  Really?  :(
Checked in, with the tests.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Depends on: 404986
No longer depends on: 404986
Amazon fixed the page also.
VERIFIED on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007112305 Minefield/3.0b2pre ID:2007112305; the menus all display correctly now.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: