Bug 282942 – safari scroll bar going beyond top of the screen after requestFullscreen

• Component: DOM
• Status: RESOLVED INVALID

[Andrew Hodel]

There are reports of this but nothing in this bug tracker.

https://discussions.apple.com/thread/3259666?sortBy=rank

https://discussions.apple.com/thread/253322722?sortBy=rank

[Alexey Proskuryakov]

Thank you for bringing this up. Could you please post a full bug report here, ideally with a screenshot? I looked at the discussion threads, but it's still not clear to me. They even seem to be about potentially different issues, something at the top vs. scroll bar at the right?

[Andrew Hodel]

Created attachment 473198 [details]
video showing problem

This is how it looks after element.requestFullscreen.

[Karl Dubost]

Andrew, is there a specific URL we could access to reproduce the issue ourselves and investigate?

[Andrew Hodel]

@comment #3 not that I know of that is accessible on the Internet.

Here is another screenshot from the first link I posted in the first comment showing the same problem.

http://flic.kr/p/ajUwXr

[Karl Dubost]

wow that is an old screenshot, given the UI of Safari in this screenshot. . :) 
That said I don't see the issue. 

Watching again the video… ah gotcha, you are saying the scrollbar is taller than the viewport and so the scroll thumb is hiding.

Without a testcase, actual HTML/CSS code that will be impossible to investigate what's going on. 

Andrew is it part of a website you are working on?

[Andrew Hodel]

Karl Dubost

I disagree, a report of error indicates which routines you should confirm in the code.

It's not difficult for someone that has been working in computer programming to quickly read and interpret code and intent while looking for a particular problem once the area has been defined.

Why would you not confirm the code that draws the scroll bar and look for a miscalculation that causes it to be drawn above the viewable area?

This doesn't happen in Edge, Firefox or Chrome and it's possible that there is a counter of elements or other items causing it.  If there is a counter causing it, no demonstration code is going to help you and the video + bug should help you to believe it.

[Karl Dubost]

Andrew,
I believe there is an issue. 
I need code to be able to diagnose it, to investigate what is happening.

[Andrew Hodel]

Karl Dubost

The code of the Safari browser draws the scroll bar and places it in a location that is in units of pixels.

There is no reason you cannot look through that code and see where it is possible that it would draw it above the bounds of a Safari window.

[Simon Fraser (smfr)]

Andrew, please keep your comments civil.

WebKit/Safari is a massive codebase; finding bugs by code inspection is generally not an efficient approach. Most bugs are complex, and require specific steps to reproduce for debugging and fixing. Yes, there have been bugs in the past where Safari mis-positioned the web view that could lead to the symptoms that you show here, but I know of at least one that has been fixed in the past.

Efficient bug fixing requires accurate information, including the device and OS version the bug was reproduced on, the web page that loaded at the time, and the sequence of steps required to reproduce the bug. We don't have that information at this time, so this bug is not actionable.

[Andrew Hodel]

Simon Fraser

There is nothing in the code causing the browser to do this, there is a bug in the Safari browser.

Letting you read a bunch of minified code to try and find the problem with a different code base isn't going to help solve something that the browser should never do.

I'm not interested in giving anyone commented code to read to people for motivation to do what I am asking and fix it.  70% of the installed browser base works without this bug.

[Simon Fraser (smfr)]

This bug is not actionable as filed, and there's no evidence that it reproduces in the most recently shipping macOS version, or Safari Tech Preview.

[Alexey Proskuryakov]

We know that this works well on websites that we tested, there must be something unusual happening here. Clearly, still a bug in WebKit or Safari, but finding it by code inspection is not realistic.

I understand that this is not a satisfactory answer. If there is anything you can do to help us have a reproducible case (either giving us the access, or building and attaching a minimized test case), we'll be willing to take a look. Alternatively, we'll keep an eye out for similar reports in the future, hoping that one of them will be actionable.

[Andrew Hodel]

I am quite certain that is something that happens when using requestFullscreen on a canvas element using WebGL when there is also a pointer lock then pressing escape to exit both of those during a complex 3D scene that is updated at short intervals.

There's nothing in the code of that other than two function calls that make the difference between Fullscreen with pointer lock and only a 3D canvas.

Both requestPointerLock and requestFullscreen do not return Promise as specified on MDN.

I could show you the code and that is all you would infer from investigating it that is of use to this issue, beyond that is is belief that it is happening as motivation to look in the browser code and I understand that.

I don't understand why I would create a video of this issue that is untrue.