Closed Bug 942247 Opened 11 years ago Closed 10 years ago

NatGeo Kennedy promo site blocks Firefox for Android for not having Flash

Categories

(Web Compatibility :: Site Reports, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: miketaylr, Assigned: adamopenweb)

References

()

Details

(Whiteboard: [clientsniff] [country-all] [sitewait])

1) go to http://kennedyandoswald.com/
2) get redirected to http://kennedyandoswald.com/flash.html

I'm able to use this site in Opera Mobile even without flash.

You can reproduce on desktop too by disabling Flash.

This is an ephemeral site, but it would be worth investigating to see if there a bug they're trying to work around or perhaps a buggy lib that might be used elsewhere.
This isn't a good start..
http://cdn1.killinglincoln.nationalgeographic.com/kennedy/1386340388/assets/UnsupportedManager.js
The Flash stuff is here:
http://cdn1.killinglincoln.nationalgeographic.com/kennedy/1386340388/assets/application-07796c52b409c433bc53c995e1b450c4.js

onready:function(){Modernizr.isFirefox&&soundManager.html5Only&&(window.location="/flash.html"),

and the HTML5Only property seems to be set here:
function(){var t,e,n=me.audioFormats,i=ze&&!!we.match(/os (1|2|3_0|3_1)/i);if(i?(me.hasHTML5=!1,me.html5Only=!0
were we is navigator.userAgent
Whiteboard: [clientsniff] [country-all]
Whiteboard: [clientsniff] [country-all] → [clientsniff] [country-all] [contactready]
Website was made by Mullen (http://www.mullen.com/) for Nat Geo. Found a developer on twitter who worked on the site, reaching our to him first.
Assignee: nobody → astevenson
Status: NEW → ASSIGNED
Whiteboard: [clientsniff] [country-all] [contactready] → [clientsniff] [country-all] [sitewait]
Hey guys,

K&O.com dev here. The reason this Firefox + No Flash catch exists is to avoid a browser-crashing HTML5 video memory leak.

To give you a little background about how the site handles memory/loading, we constantly check the user's position on the site and load only what the user needs to see – everything else gets removed. The idea behind this was to not only achieve the fasted initial load time possible, but ensure a stable performance on devices with smaller memory limits. To check out the dynamic loading, open the network inspector and watch new media load as you scroll down. To see content unload, use the inspector to watch <section> with ID "scrollableSectionContainer".

Anyways, the site initially used only HTML5 video, but in testing we noticed that users would see a video, scroll past it (and therefor unload it), then scroll back up to see it again at a later point (reload it). The result was doubled memory allocation for the same video.

We tried everything we could think of to adequately remove the HTML5 video from memory (terminating all event listeners, defining all video related variables to null, deleting objects, and removing references from the DOM), however nothing proved reliable.

Flash on the other hand played very well with memory. We could instantiate a Flash video player and destroy it later to reclaim memory allocations without any issues.

We experienced this video unload inefficiency across multiple browsers, but Firefox seemed to consume memory more quickly and crash more readily.

Hope this helps!
-Joe
Hi Joe,

Did you happen to report a bug here in Bugzilla we could look at?
Hey Mike,

Unfortunately I haven't.
Bummer, that would have been interesting to dig in to. But what about the people who have Flash on their phones and use Firefox Mobile (like me, hence the bug report)?

onready:function(){Modernizr.isFirefox&&soundManager.html5Only&&(window.location="/flash.html")

Doesn't even test for the presence of the plugin, or am I missing something?
Hi Joe, thanks for a detailed answer. We should investigate and fix those memory problems with <video> - could you report a bug, or do you want us to do so?
If you guys want to report the video unload memory leak issue, that would be awesome!

Hey Mike, 

Totally misunderstood the issue! It looks like that Flash catch is behaving slightly incorrect – it isn't intended to block FF mobile. It should probably be:

(Modernizr.isFirefox && soundManager.html5Only && !isMobile){ window.location = "/flash.html" }

We will implement, test and push soon.

Good catch! Thanks,
Joe
The video unload issue is now reported as bug 962986 with a demo. Hope you can CC yourselves there, Joe, and provide any extra information if needed.

If the solution in Joe's comment above is pushed now, I suppose this bug can be closed?
Yep, works fine on my phone now. Thanks Joe!
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.