User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12 Build Identifier: 4.0b12 My monitor resolution is 1024x768. If the exact size is used for my svg graphics, if it is displayed in the browser's full-screen mode (F11), scrollbars are present there in the view (Chrome & Opera are fine). Reproducible: Always Steps to Reproduce: 1. Open the specified URL 2. Switch to full-screen mode (F11) Actual Results: There are scrollbars in the content area. Expected Results: No scrollbars. It is necessary to reduce height by one pixel to get output without scrollbars.

I can reproduce (using a 1024x600 sized SVG on my netbook with that resolution), but I don't think this is a SVG bug. I get the same issue with a 1024x600 HTML document. Generalizing summary & component.

Here's a HTML testcase that is 1024 by 768 (matching honyk's screen-resolution). honyk, can you confirm that this reproduces the bug for you?

Daniel, yes, your generalized test case behaves exactly like my svg. Thanks for investigation.

The behavior described in comment 0 is expected. The top row of pixels is not part of the content area. Firefox uses the top row to detect mouse events when the user moves their mouse to the top of the screen to show the tabs and address bar.

Probably Firefox should make the content area fill the entire screen, and put an invisible one pixel high strip OVER the top row of pixels of the content.

Perhaps, but that's not a core issue, right?

not sure how to interpret the comments, this is serious and confusing, I found this bug, many will not. and it is a 'core issue'. needs fixing asap, else the workarounds used may well be ugly. even the proposed solution seems a hack... what if the author wants something similar? anyway for the moment I use: body { overflow:hidden; } and forego the missing pixels

FYI, the same issue in IE has been fixed in IE 10 Platform Preview 3. https://connect.microsoft.com/IE/feedback/details/649191/svg-size-issue-in-full-screen-browser-mode

The bug has now annoyed me enough for me to investigate it and find a way to fix it. %) It was incredibly exciting to see how an image (e.g. a screenshot) that actually physically _pixel-perfectly_ fits into my monitor's space (especially a 4K image on a 4K monitor), is either scaled down (and therefore blurred without a reason) by just 1-2 pixels (by default) or causing scrollbars to appear (when clicked) in Firefox. In fact, the bug can be fixed extremely trivially by just replacing the following CSS rule in the "browser\omni.ja\chrome\browser\content\browser\browser.css" file: #fullscr-toggler { height: 1px; background: black; } with a more smart one: #fullscr-toggler { position: fixed; width: 100%; height: 1px; } Note that background is removed at all since it just unreasonably makes the 1-pixel top line of content (e.g. image) _invisible_ due to overlapping the content by a 1-pixel black line. For now, I've already fixed the bug for myself locally with the following rule in my user stylesheet (via the Stylish extension): #fullscr-toggler { background: none !important; position: fixed !important; width: 100% !important; }

Unfortunately, it makes the fullscreen toggler inaccessible if the fullscreen content is a full-page windowed plug-in. We can't fix this until we drop support for windowed plug-ins.

(In reply to comment #10) > it makes the fullscreen toggler inaccessible if the fullscreen content is a full-page windowed plug-in. I'm not sure what you're talking about, but some _condition_ would probably help: * if full screen mode is used for "a full-page windowed plug-in" (whatever it means), then use currently existing styles for the toggler; * for ALL OTHER cases, use the correct styles I've proposed. > until we drop support for windowed plug-ins Is that planned and when?

(In reply to Marat Tanalin | tanalin.com from comment #11) > I'm not sure what you're talking about, but some _condition_ would probably > help: > > * if full screen mode is used for "a full-page windowed plug-in" (whatever > it means), then use currently existing styles for the toggler; > > * for ALL OTHER cases, use the correct styles I've proposed. Unfortunately, such a complex logic has been refuted (see bug 729011 for details). You need to persuade Dao to land the change.