We have a new visual profile that should be followed in Web Access.
We have seen issues with how rounded borders look at the corners. The issues are worst in Chrome (and Edge) where things look bad for both SVGs and CSS border-radius. Firefox looks great for SVGs, but still has issues with CSS border-radius. I reported these issues to Chromium and Mozilla: https://bugs.chromium.org/p/chromium/issues/detail?id=1370012 https://bugzilla.mozilla.org/show_bug.cgi?id=1793094
There are some layout issues with the login page on Firefox and Chrome on Android: * The main box isn't properly centred * The bottom bar jumps around when you scroll (only on Firefox)
(In reply to Pierre Ossman from comment #300) > > * The main box isn't properly centred This issue is caused by the difference between the "layout viewport" and "visual viewport"¹: https://developer.mozilla.org/en-US/docs/Web/CSS/Viewport_concepts Basically, the contents of the page is sized and positioned assuming that the browser chrome (mainly the address bar) is hidden, but the page is actually rendered with the browser chrome taking up space. Fortunately, there is a new standard out that all browsers except Edge claim to support. It allows us to specify more precisely which of the possible viewport sizes we are interested in. However, they seem to have forgetten about media queries, which we use to determine when to show the outline or not. I've reported that issue here: https://github.com/w3c/csswg-drafts/issues/7951
(In reply to Pierre Ossman from comment #301) > > Fortunately, there is a new standard out that all browsers except Edge claim > to support. It allows us to specify more precisely which of the possible > viewport sizes we are interested in. > Argh. The presentation on caniuse was a bit misleading. It is enabled in Safari and Firefox, but Chrome will not get it until 108 (which is their development branch, so I guess features aren't guaranteed?).
(In reply to Pierre Ossman from comment #300) > * The bottom bar jumps around when you scroll (only on Firefox) This seems to be a bug in Firefox. It only happens when the address bar hides or reappears. I can see it with other pages that have a fixed element at the bottom. I'm guessing they have a delay in recalculating the visual viewport metrics, as I can see the exact same effect if I position things relative to the top, and then use "dvh" units to move it to the bottom. I've reported the issue here: https://bugzilla.mozilla.org/show_bug.cgi?id=1797964 I don't see that there is much we can do right now. Perhaps we can tweak things so that you don't see anything white when it moves around.
We've decided it's not worth the effort to improve the experience on Firefox on Android. We can't fully work around the issue, so it's not worth the complexity to just improve it slightly. It's also just a minor cosmetic issue.
Created attachment 1073 [details] screenshot when accidentally selected in sidebar We noticed an issue with the sidebar on the iPad. When we tried to move the "handle" we accidentally selected many of the sidebar items (the logo, the buttons and the clipboard headings). This feels wrong, the sidebar buttons shouldn't be selectable like this, see the screenshot.
(In reply to Fredrik from comment #354) > Created attachment 1073 [details] > screenshot when accidentally selected in sidebar > > We noticed an issue with the sidebar on the iPad. When we tried to move the > "handle" we accidentally selected many of the sidebar items (the logo, the > buttons and the clipboard headings). > > This feels wrong, the sidebar buttons shouldn't be selectable like this, see > the screenshot. This is now fixed
Comment on attachment 1073 [details] screenshot when accidentally selected in sidebar Issues regarding long press and selections in the control bar has been broken out to bug 8022.
After internal discussions, our conclusion was that now is as good a time as any to decide designs for a full suite of input elements. As part of this work, we added styling for some elements that we currently don't use. The <select> element, and regular non-submit <button> elements are examples. We want to use the same look in Web Admin, so some of this work was preparing for elements used in Web Admin. The first iteration of the <select> element was designed to look much like text input fields. However, comparisons between different GUIs showed that select-type elements more often look like buttons. During the rework of the <select> style (r39221), we discovered a bug in how :focus-visible is handled on <select> elements in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1383062
We also decided that we want ellipsis to mark overflowing input texts. This was added in commit r39225. When testing this, we discovered a bug in the browsers that prevents the ellipsis from being shown. This was reported to both Firefox and Chromium: https://bugzilla.mozilla.org/show_bug.cgi?id=1800077 https://bugs.chromium.org/p/chromium/issues/detail?id=1383144
Tested quality of the SVG screenshots in the TAG for Web Access, section Usage. The SVG objects are pixel aligned to a great extent. While the final rendered document quality is good in general, there are a few minor issues listed below for various browsers (with latest versions as of 14 Nov 2022). Firefox (106.0, Fedora36/Windows11/MacOS13) * Toolbar drag icon is a bit thin, in particular diagonal lines. Chrome (107.0, Fedora36/Windows11/MacOS13) * Extra-keys image is blurry. Edge (107.0, Windows11/MacOS13) * Toolbar image is blurry. Safari (16.1, MacOS13) * Toolbar and extra-keys images are blurry. Chromium (105.0, Fedora36) * Extra-keys image is blurry. Concerning quality of the images in the PDF version, the rendered size and resolution are acceptable albeit slightly blurry in places, but that is to be expected due to the 75% scaling applied (see commit r39236).
We had some issue when using Firefox to generate SVG screenshots: https://bugzilla.mozilla.org/show_bug.cgi?id=1800097 We seem to have found a workaround now, though.
Regarding comment 406, a new bug concerning blurry HTML TAG SVG-images has been opened: bug 8026.
We should revisit the colors used in our status popup for warnings and errors. There are two issues with the current variants: * The borders are too pronounced. Our new design avoids most borders, when they are required, they should be quite understated. We could avoid a separate color here as well, a very transparent darker overlay border is likely the best. * The red (error) and yellow (warning) colors are not shifted in saturation in the same way that our ThinLinc blue is. This gives them a different feel. To make these colors match better with our blue (and gray) we should adjust this.
(In reply to Samuel Mannehed from comment #415) > * The red (error) and yellow (warning) colors are not shifted in saturation > in the same way that our ThinLinc blue is. This gives them a different feel. > To make these colors match better with our blue (and gray) we should adjust > this. This meant to say “not shifted in hue”, instead of saturation.
Error boxes are now fixed. The issue of colour matching was more about lightness than hue, though.
That should be everything. Marking as done.
We'd like to adjust the look of the buttons. Using ALL CAPS is very rare, and the general recommendation is to avoid that. So let's stick with standard sentence capitalization.
A dashed focus outline looks a bit dated. All modern UIs seem to use a solid line. Let's see if we can make that work instead.
The control bar buttons' hover state looks a bit out of place. We don't generally use borders, and a coloured border looks more like what we use for a focused element. We'd like this to be more harmonised with the other buttons. The principle of no background or border in the "normal" state looks very good, though, so we'd like to keep that.
Issues brought up in comment 426 through comment 428 have been dealt with.
In commit r39279, there was a misassessment of button header case prevalence, and the decision to go for sentence case taken comment 426 was missed -- reopening to correct this.
The issue with button text casing (comment 437) has been resolved.
(In reply to Pierre Ossman from comment #427) > A dashed focus outline looks a bit dated. All modern UIs seem to use a solid > line. Let's see if we can make that work instead. This issue has been fixed for the control bar buttons, but remains for the submit buttons and regular buttons.
The remaining buttons have also received the same update, regarding comment 442.
Created attachment 1085 [details] Screenshot where keyboard button is active but the keyboard is gone Tested on iPadOS 15.7.1 with Edge 107 and Safari. 1. Open keyboard 2. Close keyboard using the native keyboard down symbol 3. Press "Extra keys" This results in both keyboard and extra keys to be selected, although the keyboard is down. To open the keyboard again, I had to click two times.
The issue in comment 445 turned out to be an old issue, bug 5547. So, it was not a regression from this bug.
Issues in need of attention: • Harmonize focus-visible outline effects among the different buttons. • Improve button color contrasts for combinations of hover, selected, and active states; should work on white and light grey panels -- might have to increase scope of grey colors.
I think the message on the agent-page need some love. Now it says: Please visit the login server instead. [Log in] It should be rare that users visit this page, but I've encountered two scenarios that could happen in reality: 1. The first time you try to log in on iOS without certificates. 2. Refreshing the session page by clicking the address field and then enter.
(In reply to Frida from comment #448) > I think the message on the agent-page need some love. Now it says: > > > Please visit the login server instead. > [Log in] > > > It should be rare that users visit this page, but I've encountered two > scenarios that could happen in reality: > 1. The first time you try to log in on iOS without certificates. > 2. Refreshing the session page by clicking the address field and then > enter. The reason I think it needs a tweak are: - "login server" could be confusing for an end user - The button says "log in" but it does not log in, it takes you to the login page
(In reply to Frida from comment #448) > I think the message on the agent-page need some love. Now it says: > > > Please visit the login server instead. > [Log in] For reference, the disconnect page says: Disconnected. Return to the login page by pressing the button below. [Return]
Issues mentioned in comment 447 have been resolved.
The issue outlined in comment 448 and comment 449 has been resolved.
I think the new control bar colors look good in general. However, the way :active works on selected buttons right now seems a bit weird. Here's an overview of how buttons look currently in the main control bar (N=Normal, H=Hover, S=Selected, A=Active): * N: transparent * H: thinlinc-grey * S: thinlinc-grey2 * A: thinlinc-grey2 * S+H: thinlinc-grey3 Note that the numbered variants of thinlinc-grey are darker grey colors. That means, when pressing for example the clipboard button using a mouse, it first becomes dark (H), then darker (A) on mouse down, then darkest (S+H) after mouse up, and lastly one step brighter (S) after moving the mouse away. If I then click the same button again, it first becomes darker (S+H), then brighter (A) on mouse down, then even brighter (H) on mouse up, and lastly transparent (N) when moving the mouse away. The strange part to me here is that, when clicking a selected button, it becomes brighter on :active, instead of darker. This happens because selected:hover is darker than :active. I compared this behavior with GNOME 43 on Fedora 37: * N: transparent * H: grey 10% opacity * S: grey 20% * S+H: grey 30% * A: grey 40% I think that GNOME's method above works well, it feels more natural to have :active being the darkest variant. I know we discussed having selected and :active as the same color, but I don't think it works. If we want that, we must remove selected:hover as I see it.
Created attachment 1087 [details] Screenshot showing low contrast between icon and bg on selected extra key buttons Another minor issue regarding the button colors on the extra keys panel; they look very dark. I think the contrast is too low between the icon and the background on selected buttons in the extra keys panel. The background on the extra keys panel is thinlinc-grey, but the first step (:hover) is thinlinc-grey3. This makes selected as dark as grey4. I think we can move things down one step here and set grey2 for :hover and grey3 for selected.
Created attachment 1088 [details] Screenshot where the border is hidden in the bottom The border around the content on the login content does not disappear correctly when there is an error message. As you can see in the attachment, the border line is behind the bottom graphics.
Created attachment 1089 [details] The clipboard box with the text being hidden due to the size of the text box Found another minor issue - the clipboard box has a good minimum width, but the current minimum height almost fully hides any text inside the text box.
The way we currently change colors on our buttons when hovering, selecting and clicking doesn't scale well. It works differently for each color and requires adding more colors if we want to add a new effect. We have looked at how GNOME does things, and their method seems nice. Their regular buttons are black with a low alpha value (making them appear gray on white backgrounds). When hovered, selected and clicked, they increase the alpha value in steps. GNOME's colored buttons gets a white overlay with low alpha when hovered, and a black overlay with low alpha when clicked. Copying aspects of this approach would let us get rid of all variants of our colors and make it easy to add new steps. We could also harmonize this type of styling across all buttons.
Found another issue. In Edge and Samsung Internet on Android, the session window becomes slightly taller than what is shown on the screen. The width is unaffected. Selecting the hand icon does not allow you to move around in the session, but dragging up and down on the control bar allows you to move around. I have seen this issue on both horizontal and vertical layout. Both Edge and Samsung Internet hides the address bar when scrolling down on a page, and when the address field is hidden the session fits the screen. This is a regression, in 4.14.0 the session window fits the screen for both browsers.
The issues regarding button colors in comment 465, comment 466 and comment 469 have been fixed now. (In reply to Samuel Mannehed from comment #465) > The strange part to me here is that, when clicking a selected button, it > becomes brighter on :active, instead of darker. This happens because > selected:hover is darker than :active. A combination of selected + active has been added to solve this. This new combination represents the biggest color shift level, as seen in the following table: * level0: normal * level1: hover * level2: active OR selected * level3: selected AND hover * level4: selected AND active (In reply to Samuel Mannehed from comment #466) > Another minor issue regarding the button colors on the extra keys panel; > they look very dark. I think the contrast is too low between the icon and > the background on selected buttons in the extra keys panel. Selected buttons in the extra keys panel used to become #a7a7a0, which was very dark. The colors have been modified and selected extra keys now become #b7b7b4, which is a step brighter. My testing shows that it's still visibly clear which buttons are selected. (In reply to Samuel Mannehed from comment #469) > Copying aspects of this approach would let us get rid of all variants of our > colors and make it easy to add new steps. We could also harmonize this type > of styling across all buttons. We have now implemented this approach. It applies an adaptive overlay color on top of the button background color, instead of setting different background colors when buttons are interacted with. As a result of this change, button colors have changed slightly. Here's a comparison of the button colors with the new overlay versus if they were made using the old color variants: ╔═══════╦════════════════╦═════════╗ ║ State ║ Color variants ║ Overlay ║ ╠═══════╩════════════════╩═════════╣ ║ Controlbar buttons ║ ╠═══════╦════════════════╦═════════╣ ║ N ║ #ffffff ║ #ffffff ║ ╠═══════╬════════════════╬═════════╣ ║ H ║ #dadad7 (grey) ║ #ebebeb ║ ╠═══════╬════════════════╬═════════╣ ║ A ║ #cbcbc8 (grey2)║ #d6d6d6 ║ ╠═══════╬════════════════╬═════════╣ ║ S ║ #cbcbc8 (grey2)║ #d6d6d6 ║ ╠═══════╬════════════════╬═════════╣ ║ S+H ║ #b8b8b2 (grey3)║ #c2c2c2 ║ ╠═══════╬════════════════╬═════════╣ ║ S+A ║ #a7a7a0 (grey4)║ #adadad ║ ╠═══════╩════════════════╩═════════╣ ║ Extra key panel buttons ║ ╠═══════╦════════════════╦═════════╣ ║ N ║ #dadad7 (grey) ║ #dadad7 ║ ╠═══════╬════════════════╬═════════╣ ║ H ║ #cbcbc8 (grey2)║ #c9c9c6 ║ ╠═══════╬════════════════╬═════════╣ ║ A ║ #b8b8b2 (grey3)║ #b7b7b4 ║ ╠═══════╬════════════════╬═════════╣ ║ S ║ #b8b8b2 (grey3)║ #b7b7b4 ║ ╠═══════╬════════════════╬═════════╣ ║ S+H ║ #a7a7a0 (grey4)║ #a6a6a4 ║ ╠═══════╬════════════════╬═════════╣ ║ S+A ║ #96968d (grey5)║ #949492 ║ ╠═══════╩════════════════╩═════════╣ ║ Regular button ║ ╠═══════╦════════════════╦═════════╣ ║ N ║ #dadad7 (grey) ║ #dadad7 ║ ╠═══════╬════════════════╬═════════╣ ║ H ║ #cbcbc8 (grey2)║ #c9c9c6 ║ ╠═══════╬════════════════╬═════════╣ ║ A ║ #b8b8b2 (grey3)║ #b7b7b4 ║ ╠═══════╩════════════════╩═════════╣ ║ Submit button ║ ╠═══════╦════════════════╦═════════╣ ║ N ║ #00249c (blue) ║ #00249c ║ ╠═══════╬════════════════╬═════════╣ ║ H ║ #002dc2 (blue2)║ #002eb4 ║ ╠═══════╬════════════════╬═════════╣ ║ A ║ #0036e6 (blue3)║ #0036cb ║ ╚═══════╩════════════════╩═════════╝
Changes made here split styling for buttons into a CSS file (input.css) intended to be shared between Web Access, Web Admin, the TAG and even cendio.com. However, the method we use to disable :hover on touch devices relies on JavaScript from noVNC. This means we can't use the shared CSS like we would want. Fixing this has been moved to bug 8024.
(In reply to Frida from comment #467) > The border around the content on the login content does not disappear > correctly when there is an error message. As you can see in the attachment, > the border line is behind the bottom graphics. This has been fixed now. (In reply to Linn from comment #468) > Found another minor issue - the clipboard box has a good minimum width, but > the current minimum height almost fully hides any text inside the text box. This has also been fixed. The issue in comment #492 remains.
(In reply to Linn from comment #492) > Found another issue. > > In Edge and Samsung Internet on Android, the session window becomes slightly > taller than what is shown on the screen. The width is unaffected. Selecting > the hand icon does not allow you to move around in the session, but dragging > up and down on the control bar allows you to move around. I have seen this > issue on both horizontal and vertical layout. > > Both Edge and Samsung Internet hides the address bar when scrolling down on > a page, and when the address field is hidden the session fits the screen. > > This is a regression, in 4.14.0 the session window fits the screen for both > browsers. Not sure how this was overlooked. The issue is caused by r38953 and friends, where we switched from "height" to "min-height", and the subsequent commits where we started using the "dynamic viewport" units (e.g. "dvh"). Basically, we switched from using "100%", which in browsers seem to be relative the dynamic viewport, making it equivalent to "100dvh". Instead we now have "100vh", which in practice is equivalent to "100lvh". Hence why the page is too large now. We can't easily go back to "100%" as that doesn't work unless we also go back to using "height". And we don't want to do that as that means the page cannot grow in a sane manner (which we want on e.g. the login page). Perhaps we need to special case when we are connected and use "height" only there.
To add to that, this issue should have been seen when r38953 was committed on all browsers except Firefox. Since then, both Chrome and Edge have got support for "dvh", which means the bug won't be seen there. We still see it on Edge on our Android tablet because it isn't running the latest version of Edge.
Found another issue. It's not possible to scroll using touch gestures on the disconnect page. noVNC disables touch panning unconditionally, as it never needs it.
Created attachment 1092 [details] Screenshot of the touch tap highlight in Chrome Found another issue in Chrome when using a touch screen. Our buttons get a blue highlight that we don't want. It's especially visible on the control bar buttons, see the screenshot. Fortunately, it can be disabled: https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-tap-highlight-color
Another issue: The logo in the control bar is distorted in Safari on macOS. The inspector claims the image is 27×28, scaled to 28×28. I wonder if this is similar to the issue seen on Chrome for bug 8026. I can see that the SVG has actual dimensions of 28×28.00017.
The issues in comment 492, comment 503, comment 506 and comment 508 has now been fixed. (In reply to Samuel Mannehed from comment #499) > Changes made here split styling for buttons into a CSS file (input.css) > intended to be shared between Web Access, Web Admin, the TAG and even > cendio.com. > > However, the method we use to disable :hover on touch devices relies on > JavaScript from noVNC. This means we can't use the shared CSS like we would > want. Fixing this has been moved to bug 8024. Solving bug 8024 did not prove as easy as we anticipated, and we will save that for another time. The issue that our input.css relies on noVNC code will be resolved as part of this bug. Fixing that remains.
The issue from comment 499 has now been fixed. Our input.css does not rely on noVNC code any more.
A few issues were found concerning login page margins and how the border adapts to the viewport -- they have been dealt with.
Something is broken with the :active state of buttons on touch devices. Reopening.
(In reply to Samuel Mannehed from comment #519) > Something is broken with the :active state of buttons on touch devices. > Reopening. This has now been fixed.
After the recent changes and fixes, the following needs retesting: * The clipboard textarea should not be able to become so small that the textarea-text isn't visible. * The Web Access screenshots in the TAG look correct. * The buttons behave and look correct in the following different states: - Normal - Hover - Active - Selected - Selected + Hover - Selected + Active - When tabbed to (:focus-visible) - Disabled (might have to be triggered using the browser DevTools) Note that there are three places where buttons appear in different ways: - Login button (submit) - Control bar button - Extra keys button * The session size should match the browser window size. - Browsers with dynamic viewports, where the address bar can hide (all browsers on Android) - Browsers without support for dynamic viewport coordinates (Samsung Internet on Android) * Login, agent, and disconnect page behavior in different screen sizes and when resizing the browser window. - When the page is larger than what we have space for, we should be able to scroll. - Browser touch gestures should only work when disconnected. - The page border shouldn't show too close to the edges. We should get scroll bars when the browser window is too short. - The page layout should smoothly change when resizing in different ways. - Test when the authentication error shows on the login page as well.
Retested on Android (Samsung Tab): * Firefox 108 * Chrome 108 * Edge 108 * Samsung Internet 19 Tested: > * The clipboard textarea should not be able to become so small that the textarea-text isn't visible.² Only Samsung Internet allows resizing the clipboard textarea. But it works well there. > * The Web Access screenshots in the TAG look correct. Yup. They look up to date. > * The buttons behave and look correct in the following different states:¹ Yup. Although Firefox has some issue with the :active state: https://bugzilla.mozilla.org/show_bug.cgi?id=1806400 :hover was not tested as this is a touch platform. > * The session size should match the browser window size. Seems to work fine. Everything seems to be visible. > * Login, agent, and disconnect page behavior in different screen sizes and when resizing the browser window. Layout looks good as far as I can tell.
Retested Windows 10 and 11 * Firefox 108 * Chrome 108 * Edge 108 * Samsung Internet 19 > * The clipboard textarea should not be able to become so small that the > textarea-text isn't visible. > * The Web Access screenshots in the TAG look correct. > * The buttons behave and look correct in the following different states: > * The session size should match the browser window size. > - Browsers with dynamic viewports, where the address bar can hide (all > browsers on Android) > - Browsers without support for dynamic viewport coordinates (Samsung > Internet on Android) > * Login, agent, and disconnect page behavior in different screen sizes and > when resizing the browser window. > - When the page is larger than what we have space for, we should be able > to scroll. > - Browser touch gestures should only work when disconnected. > - The page border shouldn't show too close to the edges. We should get > scroll bars when the browser window is too short. > - The page layout should smoothly change when resizing in different ways. > - Test when the authentication error shows on the login page as well.
Retested: Windows 10 * Firefox 107 * Chrome 108 * Edge 108 Windows 11 * Firefox 108 * Chrome 108 * Edge 108 Tested: > * The clipboard textarea should not be able to become so small that the > textarea-text isn't visible. When resizing, this will not block the text in the area. In all browsers > * The Web Access screenshots in the TAG look correct. This looks good and sharp In all browsers > * The buttons behave and look correct in the following different states: The changes between buttons is correct and feels modern. > * Login, agent, and disconnect page behavior in different screen sizes and All the pages look good and have a modern look to it.
Tested server build #2961 on Fedora37 with browsers Firefox 108 Chrome 108 Chromium 107 Edge 108 * The clipboard textarea should not be able to become so small that the textarea-text isn't visible. CHECK * The Web Access screenshots in the TAG look correct. CHECK Note: Chrome and Edge exhibit minor horizontal blurriness for control bar and extra keys images. * The buttons behave and look correct in the different states. CHECK * The session size should match the browser window size. CHECK * Login, agent, and disconnect page behavior in different screen sizes and when resizing the browser window. CHECK Note: (1) Content nudged slightly when scroll bar appears for Chrome, Chromium, and Edge. (2) Chromium refuses to wrap wide text, such as on the Disconnect page and the authentication error text box; Chrome and Edge refuse to wrap the latter.
Tested server build #2961 on Mac 13.1 with browsers Safari 16.2 Chrome 108 Firefox 108 Edge 108 * The clipboard textarea should not be able to become so small that the textarea-text isn't visible. CHECK * The Web Access screenshots in the TAG look correct. CHECK Note: control bar and extra keys images in Safari exhibit slight general blurriness, while the same images in Chrome and Edge exhibit slight horizontal blurriness. * The buttons behave and look correct in following different states. CHECK Note: (1) The keyboard icon appears in Safari. It can be focused via tabbing, although difficult to unfocus, as the tab chain breaks at that point. (2) Focus is broken in general in Safari, but does not appear to be a Web Access bug, as Safari displays similar behavior e.g. on www.google.com. As a consequence, unfortunately you cannot tab to the 'Log in' button via the input fields. * The session size should match the browser window size. CHECK * Login, agent, and disconnect page behavior in different screen sizes and when resizing the browser window. CHECK Note: (1) Content nudged slightly when scroll bar appears for all browsers. (2) Safari refuses to wrap wide text, such as on the Disconnect page and the authentication error text box; Chrome and Edge refuse to wrap the latter.
Retested on ChromeOS and iOS. ChromeOS: * Chrome 108 iOS (iPad mini 6th gen): * Firefox 108 * Chrome 108 * Safari 16 * Edge 107 > * The clipboard textarea should not be able to become so small that the textarea-text isn't visible. The browsers on iOS does not allow resizing of the textarea, but it works fine for Chrome on ChromeOS. > * The buttons behave and look correct in the following different states: Unfortunately found one regression from 4.14.0 in Safari on iOS - buttons on the login page no longer visually react to :active. This issue has been moved to bug 8055. Otherwise, everything looks good on the other browsers on iOS and on ChromeOS. :hover was not tested as both platforms are touch. > * The session size should match the browser window size. Yes. > * Login, agent, and disconnect page behavior in different screen sizes and when resizing the browser window. Looks good. On iOS, I tested both vertical and horizontal layout. With the button issue on iOS moved to bug 8055, there is nothing left to be done for ChromeOS or iOS.
(In reply to Tobias from comment #529) > Tested server build #2961 on Mac 13.1 with browsers > > Safari 16.2 > ... > Note: (1) The keyboard icon appears in Safari. The virtual keyboard button should not appear in Safari on macOS.
(In reply to Samuel Mannehed from comment #531) > (In reply to Tobias from comment #529) > > Tested server build #2961 on Mac 13.1 with browsers > > > > Safari 16.2 > > ... > > Note: (1) The keyboard icon appears in Safari. > > The virtual keyboard button should not appear in Safari on macOS. Epiphany on Fedora has the same problem.
The issues in comment 529 and comment 531 has now been fixed. However, some other changes for bug 7909 were accidentally committed at the same time. The virtual keyboard button fixes together with the changes for bug 7909 means we have to retest the following: * The virtual keyboard button appears on devices with a touch screen * The control bar hint shows 3 “buttons” on devices with a touch screen * The virtual keyboard button does not appear on devices without a touch screen * The control bar hint shows 3 “buttons” on devices without a touch screen * Text input fields get the correct blue outline when focused – when focused normally using mouse or touch – when focused using keyboard TAB * Textareas (clipboard) get the correct blue outline when focused – when focused normally using mouse or touch – when focused using keyboard TAB
Verified build 2963 running on Ubuntu 22.04 using our iPad with iOS 16: ✓ The virtual keyboard button appears on devices with a touch screen ✓ The control bar hint shows 3 “buttons” on devices with a touch screen ✓ Text input fields get the correct blue outline when focused ✓ when focused normally using mouse or touch ✓ Textareas (clipboard) get the correct blue outline when focused ✓ when focused normally using mouse or touch
Retested on android (Samsung tab) * Firefox 108 * Edge 108 * Chrome 108 Tested: > * The virtual keyboard button appears on devices with a touch screen Check this look good > * The control bar hint shows 3 “buttons” on devices with a touch screen Check this look great > * Text input fields get the correct blue outline when focused Look correct > * Textareas (clipboard) get the correct blue outline when focused Look correct
Tested on Windows, both with a regular desktop machine (no touch) and a laptop with a touch screen. All below scenarios behaved as expected. * The virtual keyboard button appears on devices with a touch screen * The control bar hint shows 5 “buttons” on devices with a touch screen * The virtual keyboard button does not appear on devices without a touch screen * The control bar hint shows 3 “buttons” on devices without a touch screen * Text input fields get the correct blue outline when focused – when focused normally using mouse or touch – when focused using keyboard TAB * Textareas (clipboard) get the correct blue outline when focused – when focused normally using mouse or touch – when focused using keyboard TAB
Tested on Mac 13.1 using dev build #2963. The following criteria were met: * The virtual keyboard button does not appear on devices without a touch screen * The control bar hint shows 3 “buttons” on devices without a touch screen * Text input fields get the correct blue outline when focused – when focused normally using mouse – when focused using keyboard TAB * Textareas (clipboard) get the correct blue outline when focused – when focused normally using mouse – when focused using keyboard TAB
Everything should be in order now. Closing.
