Closed Bug 1172205 Opened 9 years ago Closed 7 years ago

Amazon preloads resources with <object> tags causing the throbber to blink heavily shortly after page load

Categories

(Web Compatibility :: Site Reports, defect)

defect
Not set
normal

Tracking

(platform-rel +, firefox41 affected)

VERIFIED FIXED
Tracking Status
platform-rel --- +
firefox41 --- affected

People

(Reporter: alice0775, Assigned: karlcow, NeedInfo)

References

()

Details

(Whiteboard: [country-all] [js][content perf][sitewait][platform-rel-Amazon])

Feel the pages load slow
It is an ugly
It looks stupid

IE11 and Chrome43 looks smart.

Steps to reproduce:
1. Open http://www.amazon.co.jp/BUFFALO-2-4GHz-%E5%85%89%E5%AD%A6%E5%BC%8F%E3%83%9E%E3%82%A6%E3%82%B9-3%E3%83%9C%E3%82%BF%E3%83%B3-BSMOW20SBK/dp/B00XJ6OM7E/ref=lp_3451982051_1_1/378-7295726-4789439?s=computers&ie=UTF8&qid=1433556380&sr=1-1

Actual Results:
Tab title flicker while page is loading. (Title and “Connecting…” alternately flicker)

Expected Results:
Should not flicker
Component: General → Tabbed Browser
Thanks for reporting this, Alice. I've seen it for a while but somehow didn't think that we might want to fix that.
After the page has loaded Amazon fetches "a few" deferred resources using this snippet:

> function d(b, c, d, e) {
>    var f = a.createElement(b ? "script" : "link");
>    i(f, "error", e);
>    b ? (f.type = "text/javascript",
>    f.async =!0, d && (c.indexOf("images/I") !==- 1 ||/AUIClients/.test(c))&&f.setAttribute("crossorigin","anonymous"),f.src=c):(f.rel="stylesheet",f.href=c);
>    a.getElementsByTagName("head")[0].appendChild(f)}
Amazon, shortly after the page has loaded, calls createElement(OBJECT) a dozen of times to load resources. We handle that just like iframes and show the spinner. Amazon does that only in Firefox... in Chrome it just doesn't do that.
Amazon checks for |document.documentElement.style.MozAppearance| and if that exists uses <object> elements to preload .js, .css, .gif, etc. files. So they basically visually f up every page load to preload resources possibly needed for further navigation.
Olli, not sure if you're the right person to ask about this. Should we handle <object> loads after the page's load event differently from <iframe>s in that they wouldn't trigger the throbber? Or is this an evangelism bug and we should talk to Amazon about different ways of preloading content that doesn't screw with our throbber?
Flags: needinfo?(bugs)
I'd say <object> should work as much as <iframe> when possible.
bz might remember if there is some historical baggage related to <object> here.
Flags: needinfo?(bugs) → needinfo?(bzbarsky)
Nothing I can think of offhand, but yes, I agree, we should treat <object> like <iframe> when it's loading a document.
Flags: needinfo?(bzbarsky)
Thanks, then let's move this over to Evangelism.
Component: Tabbed Browser → Desktop
Product: Firefox → Tech Evangelism
FTR, this isn't something we changed. I can reproduce this issue with Firefox back to 2012-01-01 builds. Amazon is preloading resources using <object> tags ~2.5s after the page has finished loading and that causes our throbber to go wild. They use different tags in Chrome and IE.
Summary: Tab title flicker while page is loading. (Title and “Connecting…” alternately flicker) → Amazon preloads resources with <object> tags causing the throbber to blink heavily shortly after page load
> Amazon, shortly after the page has loaded, calls createElement(OBJECT) a dozen of times to load resources. We handle that just like iframes and show the spinner. Amazon does that only in Firefox... in Chrome it just doesn't do that.

The final page has two objects elements in both blink and gecko. 

The only
   e = b.createElement('object');
is from a JS from Google. 

Changing the userAgent doesn't change the behavior in Gecko.

The Flickering is created by "Connecting…" information.


Why do we think it's a Web Compat issue?
What is the suggested fix?
Whiteboard: [country-all] [js]
Overriding document.createElement() while the page is loading shows that these 40 or so <object> elements are only created in Firefox, not in Chrome. <object> as well as <iframe> loads are treated as documents so we will show the throbber and look slow when loading the page. It looks the preload isn't happening in Chrome at all so when loading the page in Chrome it looks a lot nicer.
I wonder if you are talking about:



amznJQ.available("jQuery", function() {
  jQuery(window).load(function() { setTimeout(function() {
    var imageAssets = new Array();
    var jsCssAssets = new Array();
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/G/09/x-locale/common/buy-buttons/review-1-click-order._V171143523_.gif");
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/G/09/x-locale/common/buttons/continue-shopping._V192262037_.gif");
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/G/09/x-locale/common/buy-buttons/thank-you-elbow._V192261665_.gif");
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/G/09/x-locale/communities/social/snwicons_v2._V383421867_.png");
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/G/09/checkout/assets/carrot._V192555707_.gif");
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/G/09/checkout/thank-you-page/assets/yellow-rounded-corner-sprite._V192555699_.gif");
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/G/09/checkout/thank-you-page/assets/white-rounded-corner-sprite._V212531219_.gif");
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/G/09/gno/sprites/global-sprite-v1._V333159510_.png");
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/G/09/x-locale/common/transparent-pixel._V386942697_.gif");
      imageAssets.push("https://images-na.ssl-images-amazon.com/images/I/41Dq1aXo2pL._SX35_.jpg");
      jsCssAssets.push("https://images-na.ssl-images-amazon.com/images/G/01/browser-scripts/jp-site-wide-css-beacon/site-wide-6800426958._V1_.css");
      jsCssAssets.push("https://images-na.ssl-images-amazon.com/images/G/01/browser-scripts/site-wide-js-1.2.6-beacon/site-wide-6851225134._V1_.js");

    // pre-fetching image assets
    for (var i=0; i<imageAssets.length; i++) {
       new Image().src = imageAssets[i];
    }
    // pre-fetching css and js assets based on different browser types
    var isIE = /*@cc_on!@*/0;
    var isFireFox = /Firefox/.test(navigator.userAgent);
    if (isIE) {
      for (var i=0; i<jsCssAssets.length; i++) {
        new Image().src = jsCssAssets[i];
      }
    }
    else if (isFireFox) {
      for (var i=0; i<jsCssAssets.length; i++) {
        var o =  document.createElement("object");
        o.data = jsCssAssets[i];
        o.width = o.height = 0;
        document.body.appendChild(o);
      }
    }
  }, 2000); });
});
I only saw the minified version of the code but that looks roughly like what the code did. Using <object>s in Firefox and |new Image()| in Chrome.
Any idea why the author of this code does not use new Image() for preloading in Firefox?
No idea, but we could ask Amazon if there's still a reason for that. If not we could ask them to switch to new Image().
Note that the "isIE" path is never taken: it's always set to 0 per that code in comment 13.  So Firefox is the only browser where the prefetching is done at all here...
Daniel, 

In case you are still working for Amazon, could you help us reach the person in charge of this code?
Thanks.
Flags: needinfo?(danielsi)
Assignee: nobody → kdubost
Amazon is in the process of finding the right persons.
Any updates here? This is still an issue.
Before amazon change their code, here is some abp filter that should fix this issue:

||images-amazon.com$object,domain=amazon.com
!whitelist videos
@@||images-amazon.com/images/*/video$object,domain=amazon.com
@@||images-amazon.com/*.mp4$object,domain=amazon.com

Replace amazon.com to your local amazon web site like amazon.co.jp , but don't change images.amazon.com
I doubt any additional confirmation is needed, but in case it is I thought I would comment. After reading this I started up firefox with charles proxy, and set up a response body replace for the javascript file ending with ".rendering_engine-not-trident.min._V2_.js" to replace "MozAppearance" with "MozXAppearance" to break the browser detection.

Sure enough, performance when browsing Amazon shot way up and I had barely an issue with the browser stuttering and the throbbing problem disappeared. Website itself worked absolutely fine.
So.. if/when we drop the "-moz"-prefixed appearance this might solve itself? ;-p
I can confirm that the AdBlockPlus filter in comment 21 improves Amazon page load speed for me. Adding an AdBlockPlus filter is not intuitive, you must navigate to Tools -> AdBlockPlus -> Filter Preferences then create a new filter group, then drag the arrows at window right to reveal the actual filter settings. The code from #21 would be pasted there. Screenshot: http://glui.me/?i=bgmgdfauahsdk15/2015-08-03_at_2.33_PM.png/
(Sorry, first post didn't format correctly: this is a redo.)

Newbie here at bugzilla adding my two-cents worth:

I got tired of dealing with the abysmal load times of amazon.com pages and decided to run some tests and utilize some measurement tools in the browsers to see what going on, namely using Developer Tools (Network) in IE11 and Web Developer (Network) in Firefox 35.01, which provide similar information, namely both detailed graphs of every request and response made for a page in real time. 

To set the stage, I have Comcast high-speed networking, which DSL Reports' Speedtest typically shows 17 Mbps download and 3.5 Mbps upload speeds. My PC is a highly-optimized Panasonic CF-53 (Intel i5) running Windows 7 Pro with 8 GB RAM and a 1TB Samsung EVO 850 SSD.

The browsers I tested are Firefox 35.01 and Internet Explorer 11 with Java 8.45 and the latest version of Flash 17 (I actually ran these tests a few months ago).

The tests I ran all involved an amazon.com link for Polk bookshelf speakers. I ran two basic sets of tests: one set of tests were run with an emptied cache and one set was run by reloading the Polk tab after the cache had been written so as to compare amazon tab loading with and without cached results. The Firefox tests were further broken down into three groups: Safe Mode with no extensions, with Adblock Plus standard filters, and with Adblock Plus standard filters plus additional custom filters to filter out additional ads and other amazon garbage. This resulted in eight sets of tests, two in IE11 and six in FF35.

Finally, I repeated all eight sets of tests for the Polk link but using amazon's mobile version of their web site by first accessing amazon.com/mobile to set the mobile site cookie. Thus I ran 16 different test scenarios, running each scenario about a dozen times each and taking averages of the results.

For each test, in the table below, I show the number of object-load requests the web page makes back to the amazon servers, the number of seconds the pages take to load, and the number of megabytes loaded. However, note that these numbers can't be taken absolutes as there was a certain amount of variation from test to test, and I ran only about a dozen tab reloads for each of the sixteen cases.

I had initially assumed that Firefox was the culprit and also that disabling javascript on amazon was the bandaid fix for Firefox. I had also assumed that IE11 did a better job in caching than FF35. All three assumptions were incorrect. As can be seen from the numbers below, IE11 is every bit as slow as FF35, it's just that the FF35 tab progress throbber is more honest in showing the progress of web pages loading, so it just SEEMS  like the pages load slower in FF35 than in IE11. Also, turning off javascript in FF35 simply reduces the number of load requests for various page objects, which of course would speed up the page loads, though of course with the loss of important functionality as well. It can also be seen that FF35 does a significantly better job in caching than IE11, significantly reducing tab reload times. One final caveat is that for some reason the last request in the IE11 pages was a POST request that occurred a few seconds after all other objects had loaded. If the time for this POST to occur is ignored, IE11 actually loads the pages faster than FF35, at least for the non-cached case, because FF35 beat the pants off of IE11 in the cached case as IE11 apparently does not do a good job of caching the amazon pages.

Another surprising result was that the IE11 page loads produced SIGNIFICANTLY more object load requests back to the server than did FF35: I have no explanation for this at all. Another interesting result is that Adblock Plus did a very good job in reducing object load requests back to the amazon servers for FF35, but did not have a significant impact on the overall performance. Same with my custom Adblock Plus filters on FF35, that is, they reduced requests by a small amount but didn't improve performance.

Finally, I ran all eight tests again by starting with amazon.com/mobile. And this is where we see really interesting results, AND, finally, see why the amazon.com pages are so horribly slow in loading, namely for the Polk bookshelf speakers, the amazon.com non-mobile site makes 3 to 5 times as many object-load requests as their mobile site, takes almost 15 times longer to load, and loads 10 times as much data as their mobile site!

The bottom line is that non-mobile amazon.com web pages are gross pigs on both IE11 and FF35, loading massive amounts of ads and objects never actually used. For example, I looked at some of the objects being loaded and was astounded to see that most images being loaded never actually appeared on the page. Also, there were numerous ads being loaded that contributed to the slowdown.

My advice to amazon is to clean up their act if selling stuff is really their primary purpose in life. And my advice to customers is to use Firefox with Adblock Plus and/or simply to switch to using the mobile web site from their PCs and see if they find the mobile functionality sufficient.

The test results:
												
http://www.amazon.com/Polk-Audio-Bookshelf-Speakers-Cherry/dp/B000V2UBSI/ref=sr_1_1?ie=UTF8&qid=1431811808&sr=81&keywords=Polk+Audio+RTI+A1+Bookshelf+Speakers+%28Pair%2C+Cherry%29


......................................Amazon (Full Site)


..........Number Requests..............|...........Seconds............|.........Megabytes

........IE11...FFsafe..FFadblk..FFcust.|.IE11..FFsafe..FFadblk.FFcust.|.IE11..FFsafe..FFadblk.FFcust

NoCache.297 ......48......210....198...|..14......15.......14.....14..|..11......11.......11.....11
Cached..254 .....172......138....126...|..13......10........7......7..|..11.......7........7......7
	  	  	  	  	  	  	  	  	  	  	  	 
	  	  	  	  	  	  	  	  	  	  	  	 


http://www.amazon.com/gp/aw/d/B000V2UBSI/ref=mp_s_a_1_1?qid=1431811095&sr=8-1&pi=AC_SX110_SY165_QL70&keywords=Polk+Audio+RTI+A1+Bookshelf+Speakers+%28Pair%2C+Cherry%29

......................................Amazon (Mobile Site)

..........Number Requests..............|...........Seconds............|.........Megabytes

........IE11...FFsafe..FFadblk..FFcust.|.IE11..FFsafe..FFadblk.FFcust.|.IE11..FFsafe..FFadblk.FFcust

NoCache..90.......53.......43......43..|.3.4......2.6......3.....2.9..|..1.3.....1.3.....1.3....1.3
Cached...60.......53.......43......43..|.3.3......2.7......2.....2.9..|..1.3.....1.3.....1.3....1.3
(In reply to Asok Asus from comment #25)


I didn't get your point for this test honestly.

The reason Firefox on Amazon currently has no thing to do with "slow" or "throbber be more honest".. yeah, it may load faster than IE11 or even Chrome, but the problem here is when it is loading, it is *lagging* in terms of UI responsiveness. Other browsers don't have this problem.

I can't tell for IE but on Chrome, Amazon still takes years to be fully loaded (check throbber) but I can browse it smoothly meanwhile. On Firefox, throbber blinking is a thing, but what the real deal is the UI lagging during loading.

And I believe we already located the cause of the problem (poor handling for massive <object>s). Just need someone to improve its performance from Firefox side or Amazon side.

And the reason behind it is already known
I'm an engineer at Amazon who works with prefetching. The specific code Karl Dubost pointed out is not the minified prefetching logic my team provides on many pages on Amazon, but it seems to be derived from ours.
 
I'm hoping I can get help with a few issues so that I can improve how we prefetch in Firefox. 
 
1. Regarding use of new Image() in Firefox: in my testing, CSS or JS files prefetched via Image objects are not available in the browser cache. Should Image() work for CSS and JS?
 
2. When a crossorigin attribute is used on the actual file load, Firefox will not use files that were prefetched with any method I've tried. I have not found a way to specify the crossorigin attribute at the time of preloading with objects, or images, or even when using the formally supported link approach.
 
For example, this prefetched file on one page:
 
<link rel="prefetch" href="/cacheable/file.js" />
 
Will never be used by this script on a subsequent page:
 
<script src="/cacheable/file.js" crossorigin="anonymous"></script>
 
I've tried with and without "crossorigin" or "as" attributes on the <link> tag to no avail.
 
3. The <link rel="prefetch" ... /> approach in Firefox will never request more than one file at a time, compared with the maximum of five I typically see in Chrome. This limits the appeal of this approach as compared with something custom.
 
Thanks,
Drew
Drew, 
Thanks a lot for the background info.

Jonas, 
Do you know who is in charge of this part of the code?
see Comment #28 from Drew Stamps.
Flags: needinfo?(jonas)
I'd recommend talking to the DOM team (which I'm not part of since a while back).
Flags: needinfo?(jonas)
fwiw - it was recently identified (in whatwg?) that rel=preconnect needed a crossorigin attribute, it makes sense prefetch could use it too. I would start that conversation by copying ilya grigorik

hopefully :hurley can comment on how hard it would be to give prefetch some parallelism.
Blocks: 1125575
So... after seeing the email ping about this in my spam box and spending some time with nsPrefetchService, it doesn't seem like it would be world-endingly difficult to support parallelism for link rel=prefetch. Probably would just have to keep a list of ongoing prefetches, instead of a pointer to the currently-active prefetch, everything else looks at first glance to be not dependent on only one happening at a time.

Of course, I have been proven wrong in the past (and expect to be in the future), and this is my first time looking at nsPrefetchService, so take my evaluation with a grain of salt :)
> Should Image() work for CSS and JS?

Unclear.  Once we detect it's not image data I expect we cancel the load, since there's no point continuing on with it.  Seth, can you confirm?

> I have not found a way to specify the crossorigin attribute at the time of preloading
> with objects, or images, or even when using the formally supported link approach.

So the basic issue there is that loads with different CORS modes will return different data, in general, so can't share the same object cache entry.  I don't know whether or how it interacts with the HTTP cache offhand, but wouldn't be surprised if there were similar logic there or something.  We should definitely add a way to do a prefetch with a given CORS mode.
Flags: needinfo?(seth)
(In reply to On vacation August 4-25.  Please mail manually if really needed. from comment #33)
> > Should Image() work for CSS and JS?
> 
> Unclear.  Once we detect it's not image data I expect we cancel the load,
> since there's no point continuing on with it.  Seth, can you confirm?

We will definitely cancel it if we can't determine the content type to be something we can decode as an image. In particular, if content type sniffing fails (which it should on CSS/JS files) and the HTTP content type doesn't insist that the data is an image (either no |Content-Type| is specified, or the content type is a non-image content type) then we'll cancel the load.

If the server lies about the content type in the HTTP headers, that'd convince us to keep loading; we wouldn't detect the error in that case until decoding started.
Flags: needinfo?(seth)
Whiteboard: [country-all] [js] → [country-all] [js][content perf]
Thanks for the information about image file loading. It's good to understand exactly why CSS and JS prefetching using that approach is unworkable in Firefox.

It sounds as though browser modifications will be required to support either prefetching with crossorigin attributes or prefetching multiple assets in parallel. Is there a way for me to follow the progress of those changes, or to create them as feature requests myself if that would be helpful?
Depends on: 1213443
I filed bug 1213443 on the parallelism thing.

I also looked at the http code and didn't obviously see what would cause CORS to miss cache entries created by prefetches.  Nick, do you know what's going on there?
Flags: needinfo?(hurley)
Blocks: 1213469
(In reply to Boris Zbarsky [:bz] from comment #36)
> I filed bug 1213443 on the parallelism thing.
> 
> I also looked at the http code and didn't obviously see what would cause
> CORS to miss cache entries created by prefetches.  Nick, do you know what's
> going on there?

I don't know anything about the interaction between CORS and prefetched cache entries; the only thing I see around CORS in nsPrefetchService is a mention of nsILoadInfo::SEC_ALLOW_CROSS_ORIGIN_DATA_INHERITS, though being totally unfamiliar with our CORS implementation, I have no idea what that means :)
Flags: needinfo?(hurley)
That means that the fetch in prefetchservice is done without CORS and allows cross-origin fetches.  If it were done with CORS the flag would be SEC_REQUIRE_CORS_DATA_INHERITS.

OK, so why would the prefetch lead to a cache miss here?  Drew, do you happen to have a simple page showing this problem in action?
Flags: needinfo?(stamps)
Thanks, Boris.

The simple repro is basically what I described before: prefetch a JavaScript file, then on a subsequent page use the same file in a script tag with a crossorigin anonymous attribute.

Note that I watch network requests in Wireshark, because the Firefox debugger doesn't seem to indicate cache hits or misses for this. I reproduced the behavior again just now in Firefox 41.0.1.

So, with these three HTML pages:

(A): http://z-ecx.images-amazon.com/images/G/01/stamps-test/firefox/cdn-prefetch._V1_.html
(B): http://z-ecx.images-amazon.com/images/G/01/stamps-test/firefox/cdn-script._V1_.html
(C): http://z-ecx.images-amazon.com/images/G/01/stamps-test/firefox/cdn-script-anon._V1_.html

(A) has a prefetch link for jQuery, from the public Google APIs server, which is cacheable.
(B) includes the same jQuery as a regular script tag.
(C) includes the same jQuery as a regular script tag, but with a crossorigin="anonymous" attribute.

To repro:
1. Clear the Firefox browser cache.
2. Load (A). Observe that a request is made to ajax.googleapis.com.
3. Load (B). Observe that no request is made to ajax.googleapis.com; jQuery is coming from the cache.
4. Load (C). Observe that a new request is made to ajax.googleapis.com. The cached version of jQuery was apparently not used.
5. Loading any of the pages again will not cause a request to ajax.googleapis.com, so seemingly "both" copies of jQuery are cached. (Some kinds of reloads may result in a GET/304 Not Modified exchange, but not a full file request.)
Flags: needinfo?(stamps)
Drew, thanks for those links.

Looks like the key bit is anonymous vs non-anonymous load.  We end up deep in the cache guts, where those different sorts of loads do not share cache entries (which makes sense, really).  So sounds like we need a way to do anonymous prefetch.  Filed bug 1214819 on this.
Depends on: 1214819
For testing, here's a page with the prefetch link also including crossorigin="anonymous":

(D): http://z-ecx.images-amazon.com/images/G/01/stamps-test/firefox/cdn-prefetch-anon._V1_.html
It appears that both bugs that came out of this bugs were fixed in Fx44, which is now shipping to our users. Are there any updates here for what issues remain for getting this behavior fixed in Firefox?
Flags: needinfo?(danielsi) → needinfo?(stamps)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #42)
> It appears that both bugs that came out of this bugs were fixed in Fx44,
> which is now shipping to our users. Are there any updates here for what
> issues remain for getting this behavior fixed in Firefox?

For what it's worth, I'm running Firefox 44 and it's still slow as molasses here, compared to anything webkit/blink-based. Everytime I am foolish enough to open multiple tabs with Amazon links in Firefox, I have to wait for all of them to load fully before I can do anything. Even just loading the homepage and scrolling down to the bottom produces UI-locking lag.

The only workaround I found to make the issue a bit better is to use a filters list, as seen on https://www.reddit.com/r/firefox/comments/3dgaem/fix_slow_amazon_under_firefox_without_losing/
Jeff: right, because Amazon is doing different things in Firefox and Blink and the things it's doing in Firefox are really slow (and not really possible to make faster; it's creating tons of extra iframes, basically).

The thing that changed in Firefox 44 is that the things Amazon that claimed it needed so it could stop doing the really slow stuff are now present.  But what needs to happen now is for Amazon to update their code.  That's what comment 42 is about: asking the Amazon folks on this bug whether they can do that or whether there's something else they need, and if so what.
Drew,

In the hope you are still receiving information about this bug. Now that Firefox has been fixed. Firefox 44, and that the production release of Firefox is now 45.0.2, would it be possible to remove the hack which was put in place for Firefox?

Thanks.
I also tried to send an email to drew directly.
Someone from Amazon informed me by email, that they are contacting the right team. Drew is working now on another project.
Flags: needinfo?(stamps)
Hi all - I’m an engineer at Amazon. I’m familiar with a lot of the code here and can be a liaison to the team that currently owns much of this.

After reading through the bug, it looks like there are a few separate issues.

1) The first issue called out in the bug is about Firefox’s visual treatment for the throbber during downloads like these. This particular issue does not seem to be addressed later in the bug, unless I’m missing something. Have you all looked into why the throbber does this, and if this visual treatment is in fact desired behavior?

2) The bug says that underlying issues in FF have been fixed in V44. When I use FF 45 on my mac to try the repro case posted in Comment 39, I still see that in step C it does not re-use the version from cache. Am I missing something?

3) As far as a longer term solution is concerned, is it your understanding that we should be able to use IMG objects for this in Firefox (like in Chrome)? We want to be able to ideally fetch JS, CSS, and IMG assets, with events thrown when a fetch succeeds, though can use different techniques by type if needed. We want to ensure that JS and CSS are only fetched - not parsed - and are available for later use. Looking at the code I currently see ways we can likely reduce usage of OBJECT, but I’d prefer to eliminate it if possible. 

4) Slow Amazon (per comment 43)- we haven’t seen the page become unresponsive as a result of this downloading activity. I just tested in FF45 and the ESR version on mac and PC and cannot repro. We also use FF extensively inside Amazon and don’t see other reports of this. I’m very interested to know if this is a real issue with responsiveness or whether it may be people misinterpreting throbber activity for an unready page.
> Have you all looked into why the throbber does this, and if this visual treatment is in fact desired behavior?

It does that because those are subdocument loads.  Chances are, it is in fact the desired behavior, at least if we have that behavior for <iframe>.  In any case, that's a UI issue and I'm more interested in the rendering engine parts of this.

> When I use FF 45 on my mac to try the repro case posted in Comment 39

The repro case posted in comment 39 is not using crossorigin="anonymous" on the <link rel="prefetch">.  It should be, if it later wants to load the same thing with the "anonymous" CORS mode.

Or put another way, the fix for that repro case was that we added the ability to do the prefetch correctly, which did not use to exist before.  But that actual testcase is doing the prefetch wrong (differently enough from the actual load that the data can't be reused).

> As far as a longer term solution is concerned, is it your understanding that we should be able to use IMG objects for this in Firefox (like in Chrome)?

No, we have no plans to change the <img> behavior at this time.  <link rel="prefetch"> should be the right thing here, instead of <img> hacks...

> with events thrown when a fetch succeeds

That's the first time someone has mentioned an event indicating success.  We could add firing of a load event on <link rel="prefetch">, I would think.  Would that do what you want?

> I’m very interested to know if this is a real issue with responsiveness

It could well be depending on how many things you preload and how much RAM the user has.  Loading something in an <object> requires a lot more memory than just prefetching it, obviously.
(In reply to Boris Zbarsky [:bz] from comment #49)
> > Have you all looked into why the throbber does this, and if this visual treatment is in fact desired behavior?
> 
> It does that because those are subdocument loads.  Chances are, it is in
> fact the desired behavior, at least if we have that behavior for <iframe>. 
> In any case, that's a UI issue and I'm more interested in the rendering
> engine parts of this.


It seems that bug 1213438 was filed to remove the "Connecting..." text for fetches after the main page has completed, but at the discussion there was some agreement that the throbber spinning should probably go away too, but eventually the patch which landed didn't touch the throbber.

I don't think there has been any followup activity since it landed some 4 months ago.
(In reply to Avi Halachmi (:avih) from comment #50) engine parts of this.
> ...
> It seems that bug 1213438 was filed to remove the "Connecting..." text for
> fetches after the main page has completed, but at the discussion there was
> some agreement that the throbber spinning should probably go away too, but
> eventually the patch which landed didn't touch the throbber.
> 
> I don't think there has been any followup activity since it landed some 4
> months ago.

Thanks - Browsers have been intentionally providing less and less UI feedback of this sort over the years because it can drive customers to wait when it's not necessary. For example, if I use this same OBJECT approach in Chrome, it does not do the equivalent flashing behavior.

Any chance that this would change in FF?

(In reply to Boris Zbarsky [:bz] from comment #49)
> > When I use FF 45 on my mac to try the repro case posted in Comment 39
> 
> The repro case posted in comment 39 is not using crossorigin="anonymous" on
> the <link rel="prefetch">.  It should be, if it later wants to load the same
> thing with the "anonymous" CORS mode.

Great - we can experiment with prefetch again. 

> > with events thrown when a fetch succeeds
> That's the first time someone has mentioned an event indicating success.  We
> could add firing of a load event on <link rel="prefetch">, I would think. 
> Would that do what you want?

We’d ideally like events for load success and load failure. 
When we’ve tried using prefetch in the past we have run into a variety of different failure cases. Years ago, we found it caused frequent crashes of the browser. Later, we found cases where we would add prefetch links to the page through script and it would frequently never initiate a request for those assets. We’ve had better luck creating iframes that reference them but that feels hacky as well. 
Having events for load success and failure helps us manage the number of concurrent requests being made.
(In reply to ericsc from comment #51)
> (In reply to Avi Halachmi (:avih) from comment #50) engine parts of this.
> > ...
> > It seems that bug 1213438 was filed to remove the "Connecting..." text for
> > fetches after the main page has completed, but at the discussion there was
> > some agreement that the throbber spinning should probably go away too, but
> > eventually the patch which landed didn't touch the throbber.
> > 
> > I don't think there has been any followup activity since it landed some 4
> > months ago.
> 
> Thanks - Browsers have been intentionally providing less and less UI
> feedback of this sort over the years because it can drive customers to wait
> when it's not necessary. For example, if I use this same OBJECT approach in
> Chrome, it does not do the equivalent flashing behavior.
> 
> Any chance that this would change in FF?

dolske?
Flags: needinfo?(dolske)
> We’d ideally like events for load success and load failure. 

I think we can do that, at least in cases when the node is still in the document tree.  If you remove it from the tree, events won't get fired anymore (and indeed the prefetch may be canceled).  Does that sound reasonable?
(In reply to Boris Zbarsky [:bz] from comment #53)
> > We’d ideally like events for load success and load failure. 
> 
> I think we can do that, at least in cases when the node is still in the
> document tree.  If you remove it from the tree, events won't get fired
> anymore (and indeed the prefetch may be canceled).  Does that sound
> reasonable?

Totally. If we did remove it, we'd kill any listeners we had anyway, so that sounds appropriate.
Filed bug 1268962 on firing load/error events on <link rel="prefetch">.
Depends on: 1268962
(In reply to Avi Halachmi (:avih) from comment #52)
> > > It seems that bug 1213438 was filed to remove the "Connecting..." text for
> > > fetches after the main page has completed, but at the discussion there was
> > > some agreement that the throbber spinning should probably go away too, but
> > > eventually the patch which landed didn't touch the throbber.
> > > 
> > > I don't think there has been any followup activity since it landed some 4
> > > months ago.
> > 
> > Thanks - Browsers have been intentionally providing less and less UI
> > feedback of this sort over the years because it can drive customers to wait
> > when it's not necessary. For example, if I use this same OBJECT approach in
> > Chrome, it does not do the equivalent flashing behavior.
> > 
> > Any chance that this would change in FF?
> 
> dolske?

I don't have a firm opinion here, but:

I think we should do this. I've been (mildly) watching in my browser usage for cases where this (showing a throbber after page load) is useful, and I've not really seen any. In contract, it seems like there have been multiple cases where it's not -- I've seen sites (or perhaps a Firefox bug?) where the throbber came back after page load and got stuck permaloading, and of course this bug with Amazon. Sites that do this kind of thing (loading additional content on demand) generally seem to have their own throbbers in the relevant part of the page anyway. (eg, scrolling to the bottom of an infinite-scroll Twitter page quickly and there's a throbber there, scroll down to load YouTube comments and there's a throbber there).

So it's not really clear to me that there's value in having the post-initial-load throbber, and some concrete harm from it. (And we don't seem to update the stop/reload button to reflect the state, so we'd be consistent with that.)

I didn't survey other browsers, but if they're doing the same that would further strengthen the case for this.
Flags: needinfo?(dolske)
Eric, we should now have usable load/error events on <link rel="prefetch">.  Anything else preventing you from using <link rel="prefetch"> for prefetching?
Flags: needinfo?(ericsc)
I'm out of office until mid-September. I'll evaluate when back.
Setting this issue as sitewait.
Whiteboard: [country-all] [js][content perf] → [country-all] [js][content perf][sitewait]
platform-rel: --- → ?
Whiteboard: [country-all] [js][content perf][sitewait] → [country-all] [js][content perf][sitewait][platform-rel-Amazon]
platform-rel: ? → +
Adam, can you re-ping this bug on the amazon mailing list? Thanks!
Flags: needinfo?(astevenson)
Sent a message to Eric and the mailing list.
Flags: needinfo?(astevenson)
Alice0775, would you mind re-testing? Amazon said they're seeing less than 10% of blinking that they saw before.
Flags: needinfo?(alice0775)
(In reply to Mike Taylor [:miketaylr] from comment #62)
> Alice0775, would you mind re-testing? Amazon said they're seeing less than
> 10% of blinking that they saw before.

I tested with Firefox52.b4 and Chrome 57.0.2987.13.

The loading elapsed time is almost same between them.
And spinning of the throbber is also almost same between them. No longer reproduce the blink heavily problem.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(alice0775)
Resolution: --- → WORKSFORME
Thanks for testing!

(I'm going to mark this as FIXED, because Amazon did make changes on their end, not that it matters much in practice).
Status: RESOLVED → VERIFIED
Resolution: WORKSFORME → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.