Firefox Desktop bug that will benefit all WebRTC applications leveraging Window/tab/desktop sharing, including Firefox Hello which currently implements tab and window sharing. Scenarios covered to help users better understand what they are currently sharing through Firefox: - Decoration of windows (including the Firefox window) being shared through window sharing (separate color if the shared window is a private Firefox Window) - Decoration of the tab shared through tab sharing (separate color if the shared tab is part of a private window) - Decoration of the entire desktop shared through desktop sharing
This is a breakdown bug to implement the design described in bug 1107273.
Markus, Bill: I'm asking you early here to what extent this design is feasible. Can you check out the design at http://invis.io/NW1ZPHH74 and tell us what you think about it for MacOS and Windows, respectively? It looks like a separate chromeless window with a custom outline that follows the position and dimensions of the shared window. This window-following can be done dynamically with JS, of course, but I'm interested in the outline... could that be a XUL box with border(-radius) inside a chromeless window? Then we'll look at the sharing controls at the left side (right side when RTL, I assume), which might be a XUL box that is relatively positioned with a negative margin? Thanks in advance for your thoughts!
Sorry, this sort of thing definitely is not my area of expertise.
Created attachment 8579656 [details] Mac proof of concept It looks like it is feasible, it's just a bunch of work. It'd probably be easier to implement drawing the border at the widget level, because our <panel> code might not be very welcome to this kind of use. The window that draws the border needs to be on top of our normal window, because otherwise our window's shadow will drown out the border. But if the border window is on top, it needs to be transparent to mouse events, otherwise it'd block mouse input from the shared window. On the Cocoa level, achieving this is easy, we just call [mIndicatorWindow setIgnoresMouseEvents:YES]. On the XUL level, we'd need a new API for that. But obviously, the button to stop sharing needs to be clickable, so I'd actually put that into *another* new window. This one could probably be a regular XUL panel - those move along with the parent window automatically. The other tricky part is dealing with screen edges. Our panel code automatically constrains panels to be on the screen, so we'd need some way of disabling that. But Cocoa also enforces something here: If you update a window's frame (size or position), it ensures that the window doesn't overlap the menu bar, by moving it down if necessary. So if the shared window has its top side put flush against the menu bar, the window that holds the border would be offset down slightly. Windows with a high enough window level don't have that problem. Cocoa allows those to overlap the menu bar and you can position them arbitrarily. However, if the window is on top of the menu bar, that also means that it's on top of every other window, even if the shared window itself is covered by those other windows. So that won't work. It looks like it's possible to modify the window level of the border window just before updating its frame, and then restoring the original window level. That's what my proof of concept code does, and it seems to work well. So, what about the XUL API? We could just add a XUL attribute for the window, e.g. shareindicator="true", and hardcode our border color and border width on the widget level. And the thing you can click could just be a regular XUL panel containing the white images, and have some -moz-appearance for its background that the widget layer then implements to match the appearance of the border. Does that sound reasonable?
(In reply to Markus Stange [:mstange] from comment #3) > So, what about the XUL API? We could just add a XUL attribute for the > window, e.g. shareindicator="true", and hardcode our border color and border > width on the widget level. So, looking through the other mockups, this doesn't actually seem to be sufficient. Those mockups call for different border colors in different contexts (what context is orange for?), a gradient instead of a solid color (is that a good idea in the design context of 10.10?), an inner shadow (same question), and a hover effect. And apparently the border *is* supposed to be visible on top of other apps. Interesting.
Hi Sevaan, can you help clarify the UX questions there please?
Orange is an alternate colour option and can be ignored. NI'ing mmaslaney for the other design Qs.
I have two more questions: For the hover effect, is that supposed to occur when any part of the border is hovered, or just when the button on the side is hovered? (I'm hoping for the latter.) And are you planning to add some kind of animation effect for certain events, like pulsating or blinking, or is that not something we need to take into consideration?
(In reply to Markus Stange [:mstange] from comment #4) > (In reply to Markus Stange [:mstange] from comment #3) > > So, what about the XUL API? We could just add a XUL attribute for the > > window, e.g. shareindicator="true", and hardcode our border color and border > > width on the widget level. > > So, looking through the other mockups, this doesn't actually seem to be > sufficient. Those mockups call for different border colors in different > contexts (what context is orange for?), a gradient instead of a solid color > (is that a good idea in the design context of 10.10?), an inner shadow (same > question), and a hover effect. • Orange is an alternate color and can be ignored. What are the specific implementation problems/concerns around the gradient and shadow? > > And apparently the border *is* supposed to be visible on top of other apps. > Interesting.
Shell, this is something that could improve the sharing experience on Hello a lot. It is a WebRTC platform work - could we have visibility regarding when this could get implemented?