Firefox UX in Qubes

[jkin...@mozilla.com]

I just wanted to share a bug regarding Firefox usability issues in Qubes. I spoke to Joanna Rutkowska and she suggested discussing it here.

https://bugzilla.mozilla.org/show_bug.cgi?id=1326341

My hope is that we can discover when a native window has been bordered from the window manager which we could then expose to native themes. This would allow some subtle changes to simplify the issues we have mentioned in the bug.

[drew....@gmail.com]

1.: Are you talking about the UX or the UI? (The thread says UX like you do, but then it talks about the UI, not the UX.

2.: It's not a UI bug, it's a new window and thus created the way it is. New window = new window.

3.: Reader View and the Site Information are different things entirely.

This is the way FF is built, it's that simple.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I think the tiny border around some tooltip-type windows should be
considered Qubes-specific feature, not a bug. If this is separate
window, it will have have a colorful border enforced by dom0, regardless
of what VM application wants. If you want to avoid this, don't create a
separate window (which is what you've proposed there - but I don't think
it's realistic to expect this major change).

The "Reader View" window indeed is worse case - for some reason it gets
full decoration, instead of the thin one. On Qubes gui-protocol level this
is a difference between windows with override-redirect X11 flag set or not.
But I have no idea how it looks at GTK level.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYbthBAAoJENuP0xzK19csOnUH/RgTpxbmxF6aXcb9xWdXqA22
Lj+l+kInsACIFG9Oe9wTi73pF7K8IcVQrjOjDBqOEIHQDmRJtUYwN7zsddbVLcV/
clU2o/8SNxz06ObSZ6NeEKi4AEN17+NZJk13s7qJaQVfQ/cPBtO4pHP2IfslfNvJ
VwlwmCBRmkWpH4xmPeAFEigdySLHhLBF9eRyWJ7Q5OZzqJLVL96XXbpRFlwHLcS8
Z4w0Pf+HmPv2lZJ/pDYVdbcbmWmYbSriEr8fc3l/g2EY7YYaufNKei3jgEwNrfTt
aFDgQIdH3mwGKO6KO5hC4w0b7+5DXV0vPzxqzuyGSYFkdJeTK1o85EOI3nwMguw=
=hPQC
-----END PGP SIGNATURE-----

[drew....@gmail.com]

On Friday, 6 January 2017 10:35:36 UTC+11, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Jan 05, 2017 at 06:31:33AM -0800, jkin...@mozilla.com wrote:
> I just wanted to share a bug regarding Firefox usability issues in Qubes. I
> spoke to Joanna Rutkowska and she suggested discussing it here.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1326341
>
> My hope is that we can discover when a native window has been bordered from
> the window manager which we could then expose to native themes. This would
> allow some subtle changes to simplify the issues we have mentioned in the
> bug.

I think the tiny border around some tooltip-type windows should be
considered Qubes-specific feature, not a bug. If this is separate
window, it will have have a colorful border enforced by dom0, regardless
of what VM application wants. If you want to avoid this, don't create a
separate window (which is what you've proposed there - but I don't think
it's realistic to expect this major change).

The "Reader View" window indeed is worse case - for some reason it gets
full decoration, instead of the thin one. On Qubes gui-protocol level this
is a difference between windows with override-redirect X11 flag set or not.
But I have no idea how it looks at GTK level.

The Reader View is actually a separate window. As I said, "New window = new window."

Is there a way to not have the coloured border on tool-tip type windows?

In the things I built for use, in Dom0 they are fine, but in each VM it is a little annoying at times when it has the white background overlay where it needs to really be transparent. I think that's the only real issue I have with the tooltip overlay border and background.

Or is that a really big job to add in that?

Also, is it possible to have that tooltip border skinnier? As in perhaps make it 1px of colour?

[Jonathan Kingston]

To clarify I'm not pushing for Qubes to change it's behaviour at all, you are completely doing a great thing here. As mentioned it is actually a feature that anything drawn that could position itself outside of the window gets a border (This is similar to how web page content is always clearly never overlapping the browser chrome without clear indication).

I haven't delved into the widget level representation of these windows however it would be good to know from the widgets that they have the border displayed certainly. If this isn't something dom0 exposes to the widget layer then it would be nice if Firefox can access that (That way we don't need to do OS specific CSS within the browser just implement @media (--moz-bordered-browser-window) {}. or something similar). I think the gtk method would be: get_has_frame() if we can check that it has a border then we can potentially make forks in our theme itself which really would reduce the issues mentioned in the bug.

So one of my suggestions was around changing the UX within the tooltips and various other features within the browser to have skinnier or simpler UX. The drop shadows and triangle ^ tip that comes out of permission prompts to be removed as when it is bordered it looks wrong.

Long term we could look at drawing this stuff internally though as mentioned is unlikely to change any time soon.