User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 Build ID: 20130430204233 Steps to reproduce: Go to http://upload.wikimedia.org/wikipedia/commons/1/1a/SuperDisk_voice_coil_and_eject.svg and view the page info. Actual results: The page info window will freeze.
The image is probably heavy, FF hangs and CPU use is maxed out especially to display the long string chain of the image: data:image/jpeg;base64,/9j/4S3+RXhpZgAASUkqAAgAAAAJAA8BAgAGA...
The image is definitely heavy: my 8-core computer finally got a handle on it after a few minutes (I didn't time it exactly). I don't know if we can speed up rendering the image in the preview window at all as that's more of an Image Core concern (all we do is send a command for the browser to load it)--though it might be nice to have some sort of loading/progress indicator and prevent the preview window from hanging the entire window, but I don't know if the latter is possible. We can truncate the url's length where it's listed in the window as all we need to know is that it is a data url and that there is some data but we don't need to see all of the base64 information. We should limit it to something--whether it's a hundred characters or a thousand is up to someone like Dao or Gavin, and that will help with UX and should speed things up to some extent or it may solve the problem entirely. Fixing perf in Page Info in my experience is often tricky: about all you can change at the Page-Info-level is making small changes to code that behaves inefficiently in some small way or another, but outside of that, changes become extremely complex or impossible.
Created attachment 745770 [details] Screenshot of Page Info after rendering image This is a screenshot of Page Info after rendering the image (roughly 1-2 minutes). Clearly we can truncate the url to be something shorter, but I don't know what length we want to specify and if the character limit should be for only data urls or all urls or different lengths for different protocols--we can do any of the three.
The Toolkit Error Console also truncates long URLs. Perhaps we can use the same algorithm?
(In reply to Philip Chee from comment #4) > The Toolkit Error Console also truncates long URLs. Perhaps we can use the > same algorithm? Sounds good to me.