Like we do with the legacy tool, we should use floating scrollbars in the RDM viewport for all OSes. The viewport needs a message manager to do this properly, so we should wait until we switch to <iframe mozbrowser> in bug 1240896.

I believe this is fixed by the work in bug 1240896, so I'll assign it for now.

I have confirmed with local testing that bug 1240896 will fix this.

I managed to test the floating scrollbars on FF 48.0a1 (2016-04-12) and I encountered a few issues: - If a scrollbar is clicked and without releasing the click button the cursor is moved outside the viewport and than released, the scrollbar remain selected.(If the cursor is moved back on the scrollbar area, the page is scrolled without using the click button) As an expected result - the scroll is reseted if the mouse cursor is moved out of the scroll bar focus and when the click is released, scrollbar is no longer selected. - The scrollbars are not correctly positioned. In my opinion, the scrollbars should not be displayed over the webpage because the buttons displayed under it can't be accessed and if the webpage dark colored (see the attachment) they are not visible. - Also, if there is only one scrollbar available, it is overlapped by the resize button from the bottom right side of the viewport. Should I log this issues? Note that the tests were performed on Windows 10 x64, Ubunutu 14.04 x 86 and on Mac OS X 10.11 and the issues are reproducible on all platforms.

I observed also the the scrollbars are not highlighted when hoovered or selected and they are not dismissed when are not hoovered/used. I believe that this is the expected result https://bug1241326.bmoattachments.org/attachment.cgi?id=8723117 .

(In reply to Mihai Boldan, QA [:mboldan] from comment #3) > Created attachment 8740851 [details] > scrollbars.png > > I managed to test the floating scrollbars on FF 48.0a1 (2016-04-12) and I > encountered a few issues: > > - If a scrollbar is clicked and without releasing the click button the > cursor is moved outside the viewport and than released, the scrollbar remain > selected.(If the cursor is moved back on the scrollbar area, the page is > scrolled without using the click button) As an expected result - the scroll > is reseted if the mouse cursor is moved out of the scroll bar focus and when > the click is released, scrollbar is no longer selected. Hmm, I see what you mean. I am not sure how much we can do to alter this behavior without platform changes, but let's file a bug. > - The scrollbars are not correctly positioned. In my opinion, the scrollbars > should not be displayed over the webpage because the buttons displayed under > it can't be accessed and if the webpage dark colored (see the attachment) > they are not visible. I believe they are positioned fairly well given the visual effect we are looking for: in general we want them "out of the way" like the would be on a real mobile device. But I agree, it's quite hard to find them on dark backgrounds. The OS X native floating scrollbars (you can check in Safari for example) actually do attempt to check the background color and compensate by showing light scrollbars on dark backgrounds. We could file an enhancement to attempt this kind of color detection in the future if you like. > - Also, if there is only one scrollbar available, it is overlapped by the > resize button from the bottom right side of the viewport. Yeah, this is an unfortunate consequence of placing the resize handle there. Let's file a bug for this and we can ask Helen for her UX opinion over there. (In reply to Mihai Boldan, QA [:mboldan] from comment #4) > I observed also the the scrollbars are not highlighted when hoovered or > selected and they are not dismissed when are not hoovered/used. > I believe that this is the expected result > https://bug1241326.bmoattachments.org/attachment.cgi?id=8723117 . I believe that sounds correct to me. Thanks for checking it out!

(In reply to Mihai Boldan, QA [:mboldan] from comment #4) > I observed also the the scrollbars are not highlighted when hoovered or > selected and they are not dismissed when are not hoovered/used. > I believe that this is the expected result > https://bug1241326.bmoattachments.org/attachment.cgi?id=8723117 . Hmm, wait, are saying you **do** see the behavior in that image? Or you are seeing something else?

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #6) > (In reply to Mihai Boldan, QA [:mboldan] from comment #4) > > I observed also the the scrollbars are not highlighted when hoovered or > > selected and they are not dismissed when are not hoovered/used. > > I believe that this is the expected result > > https://bug1241326.bmoattachments.org/attachment.cgi?id=8723117 . > > Hmm, wait, are saying you **do** see the behavior in that image? Or you are > seeing something else? https://bug1241326.bmoattachments.org/attachment.cgi?id=8723117 - this is an example of how the scrollbars should look. > I observed also the the scrollbars are not highlighted when hoovered or > selected and they are not dismissed when are not hoovered/used. - and above are the differences between the video and the actual result. (see the attached video) Should I log a bug for this issue as well? I've logged Bug 1264974, Bug 1264982 and Bug 1264987 for the issues described in Comment 3.

(In reply to Mihai Boldan, QA [:mboldan] from comment #7) > Created attachment 8741833 [details] > actual result.gif > > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #6) > > (In reply to Mihai Boldan, QA [:mboldan] from comment #4) > > > I observed also the the scrollbars are not highlighted when hoovered or > > > selected and they are not dismissed when are not hoovered/used. > > > I believe that this is the expected result > > > https://bug1241326.bmoattachments.org/attachment.cgi?id=8723117 . > > > > Hmm, wait, are saying you **do** see the behavior in that image? Or you are > > seeing something else? > > https://bug1241326.bmoattachments.org/attachment.cgi?id=8723117 - this is an > example of how the scrollbars should look. > > > I observed also the the scrollbars are not highlighted when hoovered or > > selected and they are not dismissed when are not hoovered/used. > > - and above are the differences between the video and the actual result. > (see the attached video) > > Should I log a bug for this issue as well? > > I've logged Bug 1264974, Bug 1264982 and Bug 1264987 for the issues > described in Comment 3. Ah okay, I think I understand now. I think it's harder to compare Windows to my example in https://bug1241326.bmoattachments.org/attachment.cgi?id=8723117 because that attachment is showing the OS X native floating scrollbars, which do have some more advanced features compared to the ones we use in the viewport on Windows and Linux. If I force OS X to use the fake floating scrollbars (by setting System Prefs -> General -> Show scroll bars -> Always) and restart Firefox, then I see the same thing you are seeing on Windows. I will attach what I see in the viewport on OS X with these fake scrollbars. So, it's a limitation of our fake floating scrollbars. I don't think we need a bug at this time, as it's a long standing issue carried over from the old RDM.

I managed to verify this bug on Firefox 49.0a1 (2016-05-05) and on Windows 10 x64, Mac OS X 10.11 and on Ubuntu 16.04 x86. The floating scrolling bars are correctly displayed. Beside Bug 1264987 I didn't found any other issue related to this bug. Also, the highlighted scrollbars when hoovered or the dismiss of the scrollbars when not hoovered it's not a must for right now (Comment 8). I am marking this issue Verified-Fixed.