Closed Bug 562722 Opened 16 years ago Closed 7 years ago

window.fullScreen = false cause fennec to resize wrongly

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Maemo
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jbos, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Build Identifier: Qt Port of Fennec I wanted to add a button into fennecs ui to switch between fullscreen and non fullscreen mode. For this i looked into browser.js http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#437 > function fullscreenHandler() { > if (!window.fullScreen) > document.getElementById("toolbar-main").setAttribute("fullscreen", "true"); > else > document.getElementById("toolbar-main").removeAttribute("fullscreen"); > } I'm not sure why you add the fullscreen true in case fullscreen is false and remove it in case fullscreen is true. Also I got the problem that switching fullscreen=!fullscreen caused that the window ended up in SizeModeNormal and not in the expected SizeModeMaximized (for window.fullScreen = false). Reproducible: Always
btw. it does not matter if I call window.maximize() or not, I always end up in Normal as soon as I say window.fullScreen=false;
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #0) > I wanted to add a button into fennecs ui to switch between fullscreen and non > fullscreen mode. > > For this i looked into browser.js > http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#437 > > > function fullscreenHandler() { > > if (!window.fullScreen) > > document.getElementById("toolbar-main").setAttribute("fullscreen", "true"); > > else > > document.getElementById("toolbar-main").removeAttribute("fullscreen"); > > } > > I'm not sure why you add the fullscreen true in case fullscreen is false > and remove it in case fullscreen is true. because when the event is fired window.fullScreen has _not_ been updated!
> because when the event is fired window.fullScreen has _not_ been updated! Oh ok. I actually thought this event to get fired by changing window.fullScreen, at least I got the impression. What would be the correct way to cause a switch of the fullscreen mode back to maximized and vice versa? What i did was, I added an observer on browser.window.fullscreen preference and added a button into fennec preferences. In case the preference was changed I changed window.fullScreen to the value of the browser.window.fullscreen preference. This is wrong i suppose?
I did some more investigation on this topic. The result is that I still do not understand what is going on. After calling MakeFullscreen with window.fullScreen = false, something in xulrunner is changing the mBounds of our toplevel nsWindow to the values 816 x 311 Pixel. After, nsWindow::Show(PR_TRUE) gets called with mNeedMove=true set. And this cause a Native Resize. http://mxr.mozilla.org/mozilla-central/source/widget/src/qt/nsWindow.cpp#2279
One addition, I looked through mxr and searched for places in the code where Show(PR_TRUE) gets called. I stumbled over: http://mxr.mozilla.org/mozilla-central/source/view/src/nsView.cpp#458 Where i stopped was the function call http://mxr.mozilla.org/mozilla-central/source/view/src/nsView.cpp#458 which does recalculate the widget bounds with this function: http://mxr.mozilla.org/mozilla-central/source/view/src/nsView.cpp#340 And there esp. all the AppUnitsPerDevPixel(); and Device Context things seem at least suspicious to me. There are known issues within maemo about the wrong/faked dpi sizes reported from x. But i didn't find any implementation of DeviceContext and maybe I'm wrong but think that is the right track.
Summary: Xul fullscreen implementation is buggy and behave strange. → window.fullScreen = false cause fennec to resize wrongly
Component: Linux/Maemo → General
OS: Linux → Linux (embedded)
Hardware: Other → ARM
Closing all opened bug in a graveyard component
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.