Created attachment 585004 [details] image testcase (2592x1936) Firefox currently fails in firefox 9-12 at keeping its image scale while zooming out. In the testcase provided is the scale on my monitor 34%. Steps to Reproduce: 1. Open testcase 2. Scale is set to your optimal viewing window 3. Ctrl-minus 4 times and image gets smaller while scale is kept constant 4. Ctrl-minus a 5th time Actual Results: 1. Scale is set to 100% and its zoom is kept 2. Image is now bigger Expected Results: 1. Scale kept at 34% and zooms out a 5th time 2. Image should be smaller
I'm no expert of Layout but here's some information I've found. When asking to zoom out at the problem level of zoom, nsStylePosition has a height and width of 0. This leads nsImageFrame::ComputeSizeWithIntrinsicDimensions() to return the intrinsic size of the image, which I guess explains how the zoom out ends up making the image larger instead (as the image is now ignoring the zoom?). The process first hits nsDocumentViewer::SetFullZoom(), which records the zoom level and then ends up calling mozilla::RestyleManager::RebuildAllStyleData(). This ends up calling mozilla:ElementRestyler::RestyleSelf() on the image frame. From what I can understand by looking at mozilla::ElementRestyler::CaptureChange() it looks like the image keeps its same width and height. The process later calls PresShell::FireResizeEvent(), which I do not understand its purpose. Later PresShell::WillPaint() is called, leading to mozilla:RestylerManager::RestyleElement() and then mozilla:ElementRestyler::RestyleSelf() again. This time mozilla::ElementRestyler::CaptureChange() returns a result of 0 for both the width and the height. I'm currently trying to understand why/how the new nsStyleContext is different at the later pass through ElementRestyler. The two runs through RestyleSelf() differ in that the hints direct the first run to call nsStyleSet::ResolveStyleWithReplacement(), and the second run calls nsStyleSet::ResolveStyleFor().
To summarize, the situation that occurs is that when the page is zoomed out enough to fit the image's intrinsic (source) size, the browser sizes the image to its intrinsic size, overriding the previously calculated size of the image. This causes the image to become bigger than expected, in my window's case bigger than the previous size of the image. This is caused in ImageDocument::CheckOverflowing(). The variable 'windowBecameBigEnough' becomes true, and then RestoreImage() is called, causing the image to be set to bigger than expected. The problem seems to be fixed by simply commenting out the call to RestoreImage(): the image keeps its originally calculated size and therefore shrinks as expected. I assume there is some reason though for the code to revert the image size like that in another use case, but I don't know what that case is.
Found the original bug report that introduced this. Needinfo'd Chris Thomas for his ancient thoughts on this.
Depends on: 301477
You need to log in before you can comment on or make changes to this bug.