Posted: July 1st, 2010 | Author: Alex Korn | Filed under: Browsers | Tags: Google Chrome, Mac OS X, WTF | No Comments »
(Edit 2013/06/28) Quick version: press Shift when you click the green “Maximize” button.
(Full version) I, along with many of my friends and coworkers, have run into issues with maximizing Google Chrome windows on Mac OS X. It seems that, when clicking on the green button in the title bar, that the window resizes vertically, but not horizontally. And when you’re actually trying to get the window to fill up the full screen, this is highly unfortunate.
What’s going on
The green button is not the Maximize button in OS X; it’s the Zoom button. As described in Chrome’s issues tracker, Chrome’s intended behavior for this button is to “size-to-best-fit, not fill-screen”. Therefore, it will only make the window wider if there is some visible content on the page that’s wider than the window is currently, i.e., if there’s a horizontal scrollbar. This page shows it quite wonderfully: there’s a 65k-pixel-wide div
at the bottom that will make the window expand to the full screen size when you Zoom. Hide the div
, and the window will only expand vertically.
How to make Zoom fill the full screen
Despite this somewhat unexpected default behavior, there are a couple ways to fill the screen anyway when Zooming:
-
Press Shift when you click on the Zoom button. This, as implemented by Chrome, will make the window fill the full screen.
-
This one has some subtlety: Under System Preferences->Keyboard->Keyboard Shortcuts->Application Shortcuts, add a shortcut for Chrome. Make the Menu Title be “Zoom” (it’s under the Window menu). Since Command+M is the keyboard shortcut for Minimize, let’s make the Keyboard Shortcut for Zoom be Command+Shift+M. Go back to Chrome and try it out your keyboard shortcut. Voila! But wait–if you just click on Zoom in the menu, it will continue to resize only vertically. What’s going on here? Because you’re pressing Shift while activating Zoom with the keyboard shortcut, it works just like pressing Shift while clicking the green button. No joke.
Versions and such:
- Chrome version:
5.0.375.8628.0.1500.52 (/always)
- OS X version: 10.6.4 (/all)
Posted: May 19th, 2010 | Author: Alex Korn | Filed under: JavaScript | Tags: Google Chrome, Holmes, JavaScript, Mozilla Firefox, PHP | 1 Comment »
So you’ve been writing some JavaScript files (or HTML files or images) and testing them in Google Chrome or Mozilla Firefox. Unfortunately, you’ve deleted the JavaScript files, forgot to check them into the repository, didn’t make a backup, and they’re gone. Don’t fear! There is still hope!
Your missing file is stored in your browser’s cache, which can be accessed by typing about:cache
into the URL box in Chrome or about:cache?device=disk
in Firefox. This will list links to every file in your cache (and thus may take a moment to open). Individual files can be accessed by going to chrome://net-internals/view-cache/[[URL]]
in Chrome or about:cache-entry?client=HTTP&sb=1&key=[[URL]]
in Firefox.
The cached version will look like the following in Chrome:
[[URL]]
HTTP/1.1 200 OK
Date: Wed, 19 May 2010 15:17:36 GMT
Server: Apache
Last-Modified: Wed, 19 May 2010 15:13:53 GMT
ETag: "18aa1e6-1761-486f3e7ebae40"
Accept-Ranges: bytes
Content-Length: 5985
Content-Type: application/javascript
00000000: fb 00 00 00 01 00 00 00 34 62 bc 3d 8a e5 2d 00 ........4b.=..-.
00000010: ef 1a be 3d 8a e5 2d 00 e3 00 00 00 48 54 54 50 ...=..-.....HTTP
00000020: 2f 31 2e 31 20 32 30 30 20 4f 4b 00 44 61 74 65 /1.1 200 OK.Date
00000030: 3a 20 57 65 64 2c 20 31 39 20 4d 61 79 20 32 30 : Wed, 19 May 20
00000040: 31 30 20 31 35 3a 31 37 3a 33 36 20 47 4d 54 00 10 15:17:36 GMT.
00000050: 53 65 72 76 65 72 3a 20 41 70 61 63 68 65 00 4c Server: Apache.L
00000060: 61 73 74 2d 4d 6f 64 69 66 69 65 64 3a 20 57 65 ast-Modified: We
00000070: 64 2c 20 31 39 20 4d 61 79 20 32 30 31 30 20 31 d, 19 May 2010 1
00000080: 35 3a 31 33 3a 35 33 20 47 4d 54 00 45 54 61 67 5:13:53 GMT.ETag
00000090: 3a 20 22 31 38 61 61 31 65 36 2d 31 37 36 31 2d : "18aa1e6-1761-
000000a0: 34 38 36 66 33 65 37 65 62 61 65 34 30 22 00 41 486f3e7ebae40".A
000000b0: 63 63 65 70 74 2d 52 61 6e 67 65 73 3a 20 62 79 ccept-Ranges: by
000000c0: 74 65 73 00 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 tes.Content-Leng
000000d0: 74 68 3a 20 35 39 38 35 00 43 6f 6e 74 65 6e 74 th: 5985.Content
000000e0: 2d 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 -Type: applicati
000000f0: 6f 6e 2f 6a 61 76 61 73 63 72 69 70 74 00 00 on/javascript..
00000000: 2f 2a 2a 0a 20 2a 20 40 61 75 74 68 6f 72 20 41 /**. * @author A
00000010: 6c 65 78 20 4b 6f 72 6e 20 3c 61 6c 65 78 6b 6f lex Korn <alexko
...
The last section (in both browsers) displays the hexadecimal representation and the text of your file. The last column of this section displays newline characters as periods in many text editors, so we can’t use it to recover the file. We’ll have to use the hexadecimal. I wrote the following PHP script, which will extract and convert the hexadecimal representation into the text version:
<?php
$cacheString = ''; // COPY THE LAST SECTION IN HERE (Use /'/\\\'/g to escape quotation marks)
$matches = array();
preg_match_all('/\s[0-9a-f]{2}\s/', $cacheString, $matches);
foreach ($matches[0] as $match)
{
echo chr(hexdec($match));
}
?>
Voilà! Your once-lost code is now found!
A couple notes:
- If your server has compression enabled (such as gzip), you’ll have to go through the extra step of unzipping the content
- Chrome version: 5.0.375.38 beta
- Firefox version: 3.6.3
Update 2011/05/14: I changed the \b’s in the RegEx to \s’s as recommended in this post on recovering gzipped files.