In full-screen browser mode, a document whose size exactly matches my resolution still shows scrollbars

RESOLVED INACTIVE

Status

()

Firefox
Toolbars and Customization
RESOLVED INACTIVE
7 years ago
13 hours ago

People

(Reporter: Jan Tošovský, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
Status: UNCONFIRMED → NEW
Component: SVG → General
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: SVG - size issue in full-screen browser mode → In full-screen browser mode, a document whose size exactly matches my resolution still shows scrollbars
Version: unspecified → Trunk
Created attachment 516689 [details]
testcase 1 (html, 1024x768)

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?
(Reporter)

Comment 3

7 years ago
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?
QA Contact: general → general
Component: General → Toolbars
Product: Core → Firefox
QA Contact: general → toolbars

Comment 7

7 years ago
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
(Reporter)

Comment 8

7 years ago
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

Comment 9

2 years ago
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.

Comment 11

2 years ago
(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.

Comment 13

13 hours ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 13 hours ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.