How to Save a Private Video from Facebook

Saving a video from your news feed or a group can be a little awkward because you’re operating within an authenticated environment (i.e. you log in to Facebook through your browser) but it’s actually pretty easy. Here are the steps:

1. Browse to the video you want to download in Facebook and start it playing.
2. Right-click the playing video and select Show video URL. Copy the URL and paste it into your browser’s address bar.
3. Still in the address bar, change “www” to “m” to bring up the mobile version of the page; hit enter to load.
4. In Chrome, hit F12 and click on the Network tab (ensure the network log is recording). I also like to check the Disable cache checkbox for convenience but if you don’t, click CTRL+F5 to forcefully reload the page and its resources from the server.
5. Play the video (click play) and locate the the last request that pops up (it should be a .mp4 request).
6. Right-click the request entry and click Copy > Copy link address
7. Paste that address into your address bar and hit enter. The video will load.
8. Right-click > Save As to save the .mp4 file

Empty ImageUrl results in empty src and duplicate request

Not exactly a new issue but an empty ASP.NET ImageUrl tripped us up today. In this case there were no visible symptoms but two requests were coming through when Fiddlering the page view: the first initiated by the user and the second initiated by the page itself towards the end of the trace. In development with a debugger attached, this was manifest with Page_Load, CreateChildControls, etc being called twice for no obvious reason.

Because I initially thought I introduced the problem with the control I was working on, I first attempted to convince ASP.NET CreateChildControls was complete; I did so by clearing the Controls collection before unleashing my own code and setting the ChildControlsCreated property true once done. Neither of these tricks had any affect and the Fiddler trace had me convinced something beyond the ASP.NET pipeline and IIS had to be at fault.

That turned out to be the case but ASP.NET was still to blame ;-)

Specifically, we were adding a server-side ASP.NET image control but not initialising its ImageUrl property; the image src was later being set by jQuery at runtime on the client side. As mentioned, there were no visible symptoms of the double request: the image src was set as expected by jQuery and everything appeared okay on the surface. The IE dev toolbar also showed image src as being correctly set and there were no 404s in the mix.

It wasn't until we looked at the raw HTML that our ever-faithful admin extraordinaire noticed the empty src="" attribute. Removing the attribute removed the problem so I can only conclude IE is helpful enough to attempt to interpret a request for an empty image as a request for the parent directory of the current page while parsing the HTML before any Javascript runs. Thanks again, IE!

Notably this problem wasn't reproducible in Firefox or Chrome.

To fix the problem, we first set a default value for the ImageUrl property but that left me feeling dirty since it was still resulting in an unnecessary request. When I realised the server-side Image tag wasn't actually being used for anything server-side anyway, I replaced it with a boring old HTML img tag with no src. Microsoft has other, equally lame workarounds for this if you're interested; note they also don't plan to fix this bug.

If you found this post helpful, please support my advertisers.

SharePoint and Chrome - Better Together

I've been using Google's Chrome browser since its first release in 2008; I've loved nearly every second of the experience. Who would've thought there was room left to innovate in the browser space? Chrome's omnibar and rapid-fire JavaScript rendering, among other tweaks, are simply light years ahead of the competition.

While I normally rely on IE for my MOSS/SharePoint editing interactions, as of late I'm making the switch to Chrome in that space as well. What I've found to date has blown my mind.

Yes the MOSS 2007 UI degrades somewhat but it's still very useable. More importantly, Chrome drastically reduces the time it takes to accomplish basic tasks like modifying page content or viewing list data. I'm not saying these are normally slow in SharePoint but they can be in the www.westernaustralia.com environment (it's an ageing site with a lot of content and a lot of customisations); some pages in particular nearly grind to a halt in IE8 with the corresponding process consuming upwards of 1GB of memory the more I interact with the page.

Chrome "fixes" many of these slowdowns I'd previously attributed to the SharePoint environment and gives me all the Chrome goodness I've come to love over the last two years. It almost makes the SharePoint editing experience pleasurable!

If you found this post helpful, please support my advertisers.