Open Bug 1401877 Opened 7 years ago Updated 2 years ago

Javascript Fullscreen API - When use mozRequestFullScreen there is a wide white space at the bottom

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Version:
55 Branch
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- ?

People

(Reporter: c.bui, Unassigned)

References

Details

(Keywords: regression)

Attachments

(5 files)

ActualResult.html
803 bytes, text/html
Details
example.png
3.49 MB, image/png
Details
before.png
3.85 MB, image/png
Details
testcase2
830 bytes, text/html
Details
bug1401877.html
773 bytes, text/html
Details
Attached file ActualResult.html — 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170919220202

Steps to reproduce:

You can reproduce by following these steps:

a) Open the attached file Fullscreen_API.html or try this code in Firefox 55.0 on Windows 10 Pro Build 15063:

<!DOCTYPE html>
 <html>
   <head>
	<script type="text/javascript">
    function requestFullscreen(){  
      var docElm = document.documentElement;
	  
	  if(document.mozFullScreen){
			document.mozCancelFullScreen();
		}else {
			docElm.mozRequestFullScreen();
		}
	}
	</script>
	
	<style style="text/css">
	img {
		position: absolute;
		width: 100%;
		height: 100%;
		object-fit: cover;
	}
	
	div {
		position: absolute;
		right: 0;
		top: 50%;
		margin-top:-25px;
		width:150px; 
		height:50px; 
		background-color:#fff;
		text-align: center;
		z-index:1;
		cursor: pointer;
	}
	</style>

	<title></title>
   </head>
  <body>
   
   <div onclick="requestFullscreen();">Toggle Fullscreen</div>
   <img src="https://dummyimage.com/1920x1080/000/fff" />
   
  </body>
 </html>


b) Click on Toggle Fullscreen


Actual results:

Not always but often if you click on the "Toggle Fullscreen" the image in Firefox does not completely go fullscreen. The screen has a wide white space at the bottom.

In the Firefox Nightly Build 57.0a1 (2017-09-19) the use of mozRequestFullScreen results that the image is not visible anymore.


Expected results:

The image will display without the wide white space at the bottom of the image.
(In reply to c.bui from comment #0)

> 
> In the Firefox Nightly Build 57.0a1 (2017-09-19) the use of
> mozRequestFullScreen results that the image is not visible anymore.
> 
> 
At least, regression window in nightly build:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=eda42451649ddd290b93ac3a8b248dc7c3ae83e5&tochange=6c07ed7d69124c3ff846dab68b96aad907a433d6

Regressed by: Bug 743198

setting full-screen-api.unprefix.enabled = false fixes the image problem in nightly.
Blocks: 743198
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Flags: needinfo?(xidorn+moz)
So, the problem in Nightly is because requestFullscreen becomes a method of the element, which means when you call it in onclick handler, it would try calling "this.requestFullscreen()" before calling the global function you define. And calling this method would make the <div> itself go fullscreen.

This is something similar to bug 1364025 (where the problem is the "fullscreen" attribute on document).

I guess it can be fixed via adding [Unscopable] on requestFullscreen method just like what was suggested in bug 1364025.

cc Anne for this. Probably worth spec change?
And for the other problem
> Not always but often if you click on the "Toggle Fullscreen" the image in Firefox does not completely go fullscreen. The screen has a wide white space at the bottom.

I think this is because you are asking the documentElement to go fullscreen rather than the image. Given that there are default padding / margin around the image, I would be surprised if the image actually occupy the whole screen without any white space.

If you want the image to become fullscreen, you should request fullscreen on the image element rather than the document element.

I think this part of problem is INVALID.
Flags: needinfo?(xidorn+moz)
See Also: → 1364025
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #3)
> And for the other problem
> > Not always but often if you click on the "Toggle Fullscreen" the image in Firefox does not completely go fullscreen. The screen has a wide white space at the bottom.
> 
> I think this is because you are asking the documentElement to go fullscreen
> rather than the image. Given that there are default padding / margin around
> the image, I would be surprised if the image actually occupy the whole
> screen without any white space.
> 
> If you want the image to become fullscreen, you should request fullscreen on
> the image element rather than the document element.
> 
> I think this part of problem is INVALID.



I think the problem

> Not always but often if you click on the "Toggle Fullscreen" the image in Firefox does not completely go fullscreen. The screen has a wide white space at the bottom.

is not INVALID.

Before firefox55 this problem did not occur on asking the documentElement to go fullscreen.
The appended testcase to reproduce the problem is very simple with that single image but for more complex applications it should work with documentElement like before.
(In reply to c.bui from comment #4)
> I think the problem
> 
> > Not always but often if you click on the "Toggle Fullscreen" the image in Firefox does not completely go fullscreen. The screen has a wide white space at the bottom.
> 
> is not INVALID.
> 
> Before firefox55 this problem did not occur on asking the documentElement to
> go fullscreen.
> The appended testcase to reproduce the problem is very simple with that
> single image but for more complex applications it should work with
> documentElement like before.

Actually I have no idea what do you mean here. It seems to me that the behavior is quite consistent, and doesn't change between 54 and 55. Could you provide some screenshot to help me understand what's the problem you're seeing?

For checking earlier version, you may want to use mozregression: http://mozilla.github.io/mozregression/install.html Note that since mozregression always uses Nightly setting, you may want to add preference "full-screen-api.unprefix.enabled" to false when running builds there.
Flags: needinfo?(c.bui)
Attached image example.png — 
Flags: needinfo?(c.bui)

    
    

    
  
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #5)
> (In reply to c.bui from comment #4)
> > I think the problem
> > 
> > > Not always but often if you click on the "Toggle Fullscreen" the image in Firefox does not completely go fullscreen. The screen has a wide white space at the bottom.
> > 
> > is not INVALID.
> > 
> > Before firefox55 this problem did not occur on asking the documentElement to
> > go fullscreen.
> > The appended testcase to reproduce the problem is very simple with that
> > single image but for more complex applications it should work with
> > documentElement like before.
> 
> Actually I have no idea what do you mean here. It seems to me that the
> behavior is quite consistent, and doesn't change between 54 and 55. Could
> you provide some screenshot to help me understand what's the problem you're
> seeing?
> 
> For checking earlier version, you may want to use mozregression:
> http://mozilla.github.io/mozregression/install.html Note that since
> mozregression always uses Nightly setting, you may want to add preference
> "full-screen-api.unprefix.enabled" to false when running builds there.

I attached the example.png. There is a wide white space at the bottom of the screen if request fullscreen. The problem just occur when the window was maximized.

    
    

    
  
(In reply to c.bui from comment #7)
> I attached the example.png. There is a wide white space at the bottom of the
> screen if request fullscreen. The problem just occur when the window was
> maximized.

But this is not the page you provided in comment 0. What page is it? How does it look like for previous version?
Flags: needinfo?(c.bui)

    
    

    
  

      
      
      
      

        Attached image
          
        before.png
        — 
      

    


  
In before.png you can see how it look like for previous version.
The page i provided in comment 0 was just a simple testcase. 
The page i provided as screenshot is the more complex one.
Flags: needinfo?(c.bui)

    
    

    
  
I cannot reproduce this issue with the simple testcase you provided. Could you try reproducing with the testcase in comment 0 and upload the screenshot comparison?

Alternatively you can provide your complex page and I can try to see whether I can also reproduce the issue with that.
Flags: needinfo?(c.bui)

    
    

    
  
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #10)
> I cannot reproduce this issue with the simple testcase you provided. Could
> you try reproducing with the testcase in comment 0 and upload the screenshot
> comparison?
> 
> Alternatively you can provide your complex page and I can try to see whether
> I can also reproduce the issue with that.

Sure, here is the url: pixmo.esignserver2.com/gallery.do
Flags: needinfo?(c.bui)

    
    

    
  

      
      
      
      

        Attached file
          
        testcase2
        — 
      

    


  
I can reproduce the white bottom problem with testcase2 on Nightly57.0a1 and 56.0b12 Windows10.


Steps To Reproduce:
1. e10s is enabled.
   full-screen-api.unprefix.enabled= false
   layers.mlgpu.enabled= false
   layers.mlgpu.dev-enabled= false
2. Restart Browser and Maximized

3. Open testcase2 (attached here)
4. Click "Toggle Fullscreen" and repeat this step(3-9 times if needed).

Actual Results:
Bottom part of screen is white

Expected Results:
Image should be expanded to bottom of screen

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e8a7790bd2685ca77713d2bf8b165e7e162a443d&tochange=81099dbf284b1af027b99a942c2d3d0043e9b208

Regressed by: Bug 1194751

@:kanru
It seem your patch causes the problem. Could you look this?
Flags: needinfo?(kchen)

    
  
Blocks: 1194751

    
    

    
  
Alice, thanks for help analyzing. I found the same regression window. Just going to post that :)

    
    

    
  
Too late for 55 and 57, Kanru can you take a look? Is this easily fixed and uplifted, or better for 58 cycle?

          status-firefox55:
          affected → wontfix

          status-firefox56:
          affected → wontfix
Assignee: nobody → kchen
Flags: needinfo?(kchen)

    
    

    
  
I can reproduce this on Windows but not on Linux.

    
    

    
  

      
      
      
      

        Attached file
          
        bug1401877.html
        — 
      

    


  
Minimal test case.

It looks like the height: 100% calculation is wrong. It's not reproducible if I set the entire document background to black.

    
    

    
  
I noticed that after entered fullscreen I can scroll the black document. So the content is correctly resized but the container frame is not. A mouse click will resize the frame correctly.

    
    

    
  
I think this is a issue similar to bug 1350875. I suspect the root cause is that the timing of content reflow happened before <browser> reflow so the content used the original size.

Currently to enter fullscreen we have to follow these sequence:

1.  Chrome window enter fullscreen -> trigger reflow
2.     <browser> changes it's size to fullscreen
3.        Content enter fullscreen

If step 3. happens before step 2. it can get wrong window size. Though this is just my guess.

Xidorn, do you have time to take a look or find someone else to? I'll be away from keyboard until 10/12 so won't be able to look further until then.
Flags: needinfo?(xidorn+moz)

    
    

    
  
I don't think it is similar to bug 1350875. That bug is linux-specific, but this can be reproduce on Windows and macOS. These systems have synchronous fullscreen change, so we have more reliably behavior.

Also, for e10s, what's happening is a bit different from your guess. In e10s, we resize the viewport of content in advance in nsDOMWindowUtils::HandleFullscreenRequests to avoid additional resize reflow, so the size should be correct since the very beginning.

It really feels more like a painting issue to me rather than reflow, actually... On Windows, a focus change would make the white bar disappear, also if I open Inspector before entering fullscreen, and use that to highlight anything, the white bar disappears as well. When the white bar disappears, the background image doesn't move or resize, which means that it has got the right geometry, and the problem is just that part of things is not drawn on the screen correctly.


[1] https://searchfox.org/mozilla-central/rev/20e41d4a61a8f5e34c9cf357304b78b3e9bced8a/dom/base/nsDOMWindowUtils.cpp#3519-3540
Flags: needinfo?(xidorn+moz)

    
    

    
  
Note although any focus change or mouse click will make the white bar disappear, the black part can be scrolled away. I think the geometry is incorrect, either in layout or in gfx/apz.
Priority: -- → P2

    
    

    
  
unassign myself. I want be able to work on this anytime soon.
Assignee: kchen → nobody
Component: DOM → DOM: Core & HTML

    
    

    
  
I also have this issue on nightly 69.0a1 (2019-05-29) (64-bit). Fullscreen videos on youtube have a white bar on top and the content itself is "pushed" down. It occurs under both Windows and Linux using a clean profile. Leaving and entering fullscreen multiple times does sometimes fix the issue.


Please tell me if there's any further info I can provide.



    
    

    
  
(In reply to Fred Uggla from comment #23)




I also have this issue on nightly 69.0a1 (2019-05-29) (64-bit). Fullscreen videos on youtube have a white bar on top and the content itself is "pushed" down. It occurs under both Windows and Linux using a clean profile. Leaving and entering fullscreen multiple times does sometimes fix the issue.


Please tell me if there's any further info I can provide.




That is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1550759, thanks.



    
  
Severity: normal → S3

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: