-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
innerHeight is incorrect and frozen #203
Comments
I've commented this out Lines 104 to 109 in 7f37640
|
These are params that are passed to |
I don't see
I suppose the simplest assertion is that Other than that probably more reliable would be to craft a HTML page with a node absolutely positioned from 0 to Or maybe try to issue a mouse click event on a positioned element -- pretty sure it won't work if the element is really outside. |
I thought about creating a 1x1 pixel buttons to test if they are clickable but if you zoom it you'd see that buttons are catching the click event on a larger area even with CSS styles applied to make them rectangle and small. Then I thought that you could screenshot a page and see (with help of chunky_png that is already in the Gemfile) how the rectangle drawn within P.S.: the |
Another thing I see (called
UPD: nevermind, it's just because of the minimal possible window size. If you increase the window, you'd see the issue is still there:
|
I would just delete that line if it does not break anything. As I said I see no reason why it's even there, since it's in the first commit. While it breaks the websites layout in the way that page does not fit the window and people have to scroll the page that would not be needed in a normal browser. At least on the headfull macOS. I see no way to fully test it without going to OS level screenshotting, and if not that then:
|
For example, craft an html page with with 4 colored pixels on the absolute coordinates, then find the UI element with applescript, screenshot the region and analyze with some chunkypng. Can be done on headfull macOS. |
How about this fix I merged to master #331 was it the reason for your issue? |
I believe I had to add it because of Cuprite that don't apply window-size on MacOS. I think after all that time it still doesn't work, so this resize on the browser start was done for that reason. |
I don't believe it's fixed. my fork: ruby 2.5 + manual patch, |
BTW why are you still on ruby 2.6? isn't easy to upgrade?) |
Can you attach the script, for me for easy repro? |
I'm removing this resize call when page is created. I think there was a confusion from my side about I think we don't need to support all this in Ferrum as it has to involve less magick than Cuprite. You can resize any page whenever you want and new pages not obliged to inherit this sizу. It's useful for capybara and tests but not for Ferrum. So I'll just move this part to Cuprite. As for incorrect and frozen innerHeight, well I guess in headless mode it goes nuts, but headful mode is ok. So this issue/question goes to Chrome team. I hope that removal of the resize call will satisfy you. Let me know please. |
The
innerHeight
is expected to be smaller thanouterHeight
: https://developer.mozilla.org/en-US/docs/Web/API/Window/innerHeightBut in fact they are equal and
innerHeight
is frozen (at 768). When I resize the window it does not change.Also because of this the third-party JS scripts are unable to correctly obtain the client area and resize the content beyond it.
v 0.11, macOS Big Sur
The text was updated successfully, but these errors were encountered: