Last Comment Bug 579119 - Amazon 'Lightning Deals' are not visible on 4.0 betas
: Amazon 'Lightning Deals' are not visible on 4.0 betas
Status: RESOLVED FIXED
[Input]
: regression
Product: Tech Evangelism Graveyard
Classification: Graveyard
Component: English US (show other bugs)
: unspecified
: All All
: -- normal
: ---
Assigned To: Kev Needham [:kev]
:
Mentors:
http://www.amazon.com/gp/goldbox/ref=...
Depends on:
Blocks: 514560 614195
  Show dependency treegraph
 
Reported: 2010-07-15 11:36 PDT by Aaron Train [:aaronmt]
Modified: 2015-04-19 23:39 PDT (History)
22 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Visible on 3.6 - 'Lightning Deals' (140.77 KB, image/png)
2010-07-15 11:44 PDT, Aaron Train [:aaronmt]
no flags Details

Description Aaron Train [:aaronmt] 2010-07-15 11:36:52 PDT

    
Comment 1 Aaron Train [:aaronmt] 2010-07-15 11:38:19 PDT
Amazon's lightning deals are not visible on Trunk. Tested on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre, and caught via Firefox Input statements http://input.mozilla.com/search/?q=amazon+lightning&product=firefox
Comment 2 Aaron Train [:aaronmt] 2010-07-15 11:44:37 PDT
Created attachment 457610 [details]
Visible on 3.6 - 'Lightning Deals'
Comment 3 Boris Zbarsky [:bz] 2010-07-15 12:30:14 PDT
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b7f3c1c9fb57&tochange=a5e1b195ecf7

The main culprit visible there is the TM merge....  Going to see whether that's it.
Comment 4 Boris Zbarsky [:bz] 2010-07-15 12:49:19 PDT
This is a site bug.  The error console says:

Error: assignment to undeclared variable Deal
Source File: http://z-ecx.images-amazon.com/images/G/01/goldbox/client-side/gbld_js-v1._V210760631_.js
Line: 368

(and in a debug build this is in fact flagged as a strict mode error).  The checkin range includes this bug:

  Jim Blandy — Bug 514560: Forbid assignments to undeclared variables in strict
  mode code. r=jorendorff 

and the script in question in fact does "use strict;" and has this lovely code starting on line 366:

  if (!window.Deal) {
  (function(){
  Deal = {};
  ...
    )();}

which is in fact something that should throw in strict mode.
Comment 5 Aaron Train [:aaronmt] 2010-09-05 15:37:11 PDT
Still not visible in 4.0b5pre Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100905 Firefox/4.0b6pre
Comment 6 Aaron Train [:aaronmt] 2010-09-05 15:38:23 PDT
Still not visible in 4.0b5pre Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100905 Firefox/4.0b6pre
Comment 7 Boris Zbarsky [:bz] 2010-09-05 19:19:58 PDT
Fwiw, I did send comments to Amazon (as a user), as well as contacting the people I know who work at Amazon.  No response to the former so far, and the latter are trying to find the right people to talk to.
Comment 8 Brendan Eich [:brendan] 2010-09-07 10:23:41 PDT
Boris, if your friends could inquire about the origin of this "use strict"; in case it came from some open source tool, or perhaps was based on bad advice in some public doc repository we could try to fix, that would be helpful.

/be
Comment 9 Boris Zbarsky [:bz] 2010-09-07 10:30:31 PDT
The origin is obvious is you look at http://z-ecx.images-amazon.com/images/G/01/goldbox/client-side/gbld_js-v1._V210760631_.js -- that file is the concatenation of several third-party and Amazon JS files, and the very first one is http://www.JSON.org/json2.js which (correctly) uses strict.  Then one of the Amazon files that comes after it isn't actually strict-mode compliant.

This concatenation pattern is not really compatible with how "use strict" is designed.
Comment 10 Brendan Eich [:brendan] 2010-10-28 12:14:25 PDT
Is anyone trying to contact amazon.com about this? They are headed into even more pain, esp. if IE9 implements strict mode.

/be
Comment 11 Boris Zbarsky [:bz] 2010-10-28 12:21:46 PDT
I've been trying since comment 7.  Sent 2 or 3 reports via their website, and my friend has been trying to get someone to respond to.  It's been a black hole so far.
Comment 12 Shawn Wilsher :sdwilsh 2010-11-10 15:20:17 PST
(In reply to comment #11)
> I've been trying since comment 7.  Sent 2 or 3 reports via their website, and
> my friend has been trying to get someone to respond to.  It's been a black hole
> so far.
I just pinged a contact there as well.  Hopefully between the two of us we get somewhere.
Comment 13 Shawn Wilsher :sdwilsh 2010-11-10 17:03:01 PST
My contact has filed a bug about it in their tracker, and will keep me posted.  Likewise, I'll report back here.
Comment 14 Shawn Wilsher :sdwilsh 2010-11-11 10:21:31 PST
Apparently there are several tickets on this.  It's on the team's radar, but no ETA on a fix yet.
Comment 15 Boris Zbarsky [:bz] 2010-12-10 11:32:07 PST
This is actually getting mentioned as a reason people are switching away from Firefox at http://lifehacker.com/5711040/browser-speed-tests-ie-9-firefox-4-beta-chromes-crankshaft-and-opera-11-beta
Comment 16 harvey anderson 2010-12-10 11:48:41 PST
Kev, 
Can you please reach out to your contacts at Amazon. I pinged our contact as well. thanks /hja
Comment 17 Oliver Hunt 2010-12-10 11:53:33 PST
From the webkit tracker -- https://bugs.webkit.org/show_bug.cgi?id=48377

 Comment #27 From Evan Martin 2010-12-09 14:11:36 PST (-) [reply] 
Amazon contact says they're planning to work on it in January.

Although i find myself wondering how much work is required to remove a single string that has no side effects other than breaking the site...
Comment 18 Robert Accettura [:raccettura] 2010-12-10 13:33:09 PST
My guess would be a production code freeze during the traffic spike.
Comment 19 Mike Shaver (:shaver -- probably not reading bugmail closely) 2010-12-10 13:34:35 PST
Getting a major e-tailer to make a change to their site during the nov-dec hypershopping season is basically impossible.  If it doesn't expose them to huge liability or cost them a ton of money, it doesn't work from a risk calculus perspective, and I have a hard time faulting them for it.
Comment 20 Sean Hicks 2010-12-29 07:12:20 PST
(In reply to comment #19)
> Getting a major e-tailer to make a change to their site during the nov-dec
> hypershopping season is basically impossible.  If it doesn't expose them to
> huge liability or cost them a ton of money, it doesn't work from a risk
> calculus perspective, and I have a hard time faulting them for it.

Perhaps this was correct.  They apparently fixed their code this morning, as the lightning deals now appear for me on Beta 8.

http://tinypic.com/view.php?pic=2mnkbc3&s=7
Comment 21 Ed Lee :Mardak 2010-12-29 07:51:18 PST
(In reply to comment #4)
> http://z-ecx.images-amazon.com/images/G/01/goldbox/client-side/gbld_js-v1._V210760631_.js
>   if (!window.Deal) {
>   (function(){
>   Deal = {};

Site seems to be using this file now:

http://z-ecx.images-amazon.com/images/G/01/goldbox/client-side/gbld_js-v39._V174650570_.js

if (!window.Deal) {
(function(){
window.Deal = {};
Comment 22 Jeff Walden [:Waldo] (remove +bmo to email) 2011-01-20 21:41:42 PST
Note that Amazon's fix for this was inadequate, because the rest of the concatenated file isn't fully strict mode-safe.  See bug 627531 for the second instance, which could very well not be the last one, although one hopes it is.  :-\
Comment 23 Andreas Goeb 2011-02-08 06:28:27 PST
To make things worse: The German Amazon website still uses the old version of the script that produces the error. So I tried the approach of Comment 7 and emailed them about the issue. Let's hope they come up with a "real" fix some day.

Note You need to log in before you can comment on or make changes to this bug.