UserAgent: Mozilla/5.0 (X11; CrOS x86_64 10895.56.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.95 Safari/537.36
Platform: 10895.56.0

Steps to reproduce the problem:
1. Move the mouse cursor to a tab title or any other clickable area, e.g. the print/save button in the print dialog (that is not rendered HTML)

What is the expected behavior?
The cursor could turn into a hand, indicating that it is something clicakble

What went wrong?
The cursor is still an arrow.

Reasoning:
This is confusing to novice users (in my case: an elder lady), that are solely relying on Chrome OS, as they have to use different mental models concerning cursor behaviour, depending on the UI context (rendered HTML vs ChromeOS UI). Such users mainly use ChromeOS for browsing the web, so their mental model is based on experiences they made within the rendered HTML.

Did this work before? N/A 

Chrome version: 69.0.3497.95  Channel: n/a
OS Version: 10895.56.0
Flash Version: 

As a (front-end) dev I'm well aware that this suggestion might not be feasible to implementab accross all contexts (e.g. in Android apps that are run in Chrome OS). Furthermore I'm aware that this behaviour is probably not wished for outside of ChromeOS. 

However I think this could be easily implementable in the Chrome UI and the for the Chrome OS UI. Possibly only enabled via a config switch.

As a UX engineer and IT supporter for elder people with Chrome OS I think it shou