xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 6 years ago

#500 closed defect (fixed)

small tooltip windows have transparency issues

Reported by: J. Max Mena Owned by: alas
Priority: critical Milestone: 0.12
Component: client Version: 0.11.x
Keywords: Cc:

Description

Some websites have a small pop-up that will display information, such as time since a post, information about a link, etc. etc.. In Xpra certain browsers will cause them to display a cross-hatching of colored lines before moving the mouse causes the proper pop-up to appear, with the lines just at the very bottom of the pop-up.

Interestingly, the pop-ups are only a problem in Chrome, not Firefox. The Firefox pop-ups are a solid white color, rather than the black (possibly partially transparent?) color in Chrome.

Currently running Xpra 0.11.x r5209 in Windows 7 64-bit. I'll attach a few screenshots to explain further.

Attachments (9)

xpra pop up bug chrome.png (88.2 KB) - added by J. Max Mena 6 years ago.
the bugged pop-up in Chrome.
xpra pop up bug firefox.png (80.1 KB) - added by J. Max Mena 6 years ago.
The pop-up working properly in Firefox
xpra pop up bug working on interfacelift.png (62.1 KB) - added by J. Max Mena 6 years ago.
The pop-up working on interfacelift in Chrome
xpra pop up bug working on twitch.png (109.9 KB) - added by J. Max Mena 6 years ago.
The pop-up working on twitch in chrome
xpra pop up bug after moving mouse.png (101.9 KB) - added by J. Max Mena 6 years ago.
Pop up working semi-properly on bmwusa after moving the mouse
xpra pop up bug twitch after mouse move.png (60.9 KB) - added by J. Max Mena 6 years ago.
pop-up showing colors after moving mouse on twitch
xprainfo.txt (32.8 KB) - added by J. Max Mena 6 years ago.
the file generated after running "xpra info | grep window > xprainfo.txt"
test-link-title.html (136 bytes) - added by Antoine Martin 6 years ago.
simplest html test case possible
ticket500_tooltip-windows-still-displaying-poorly_r5692.png (330.7 KB) - added by alas 6 years ago.
r5692 osx client chrome/lazarus tooltips still misbehaving

Download all attachments as: .zip

Change History (25)

Changed 6 years ago by J. Max Mena

Attachment: xpra pop up bug chrome.png added

the bugged pop-up in Chrome.

Changed 6 years ago by J. Max Mena

Attachment: xpra pop up bug firefox.png added

The pop-up working properly in Firefox

Changed 6 years ago by J. Max Mena

The pop-up working on interfacelift in Chrome

Changed 6 years ago by J. Max Mena

The pop-up working on twitch in chrome

Changed 6 years ago by J. Max Mena

Pop up working semi-properly on bmwusa after moving the mouse

Changed 6 years ago by J. Max Mena

pop-up showing colors after moving mouse on twitch

comment:1 Changed 6 years ago by J. Max Mena

I forgot to mention in the original post, but in some websites the pop-ups behave as expected in Chrome, and in others it shows up bugged. I'm not sure yet why.

Last edited 6 years ago by J. Max Mena (previous) (diff)

comment:2 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

I don't think the colour (black vs white) is relevant here: browsers are free to style alt tags as they wish, it may just be how those two browsers do it. You can verify this by running the browser natively (without involving xpra).

  • does this also happen on OSX?
  • does this also happen with opengl turned off?
  • does the bug occur with the default transparency test applications:
  • does this happen with transparency turned off on the server:
    XPRA_ALPHA=0 xpra start ...
    
  • xpra info|grep window captured when the tooltip window is showing could be useful too
  • does this happen with all encodings that support transparency? (all the png encodings, webp and rgb) Does it happen with encodings that do not support transparency? (jpeg)
Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 6 years ago by Antoine Martin

Priority: minorcritical

Raising the priority: I'm waiting to hear on this bug to release 0.11.1

comment:4 Changed 6 years ago by J. Max Mena

To answer your questions:

  • Yes, the same thing occurs in OSX.

Interestingly instead of turning normal when you move the mouse like it does in the screenshot, the text just shifts over a couple of pixels to the right.

  • Yes, it behaves the exact same, both Windows and OSX with and without opengl
  • The default transparency tests look as they should, both with and without opengl
  • With XPRA_ALPHA=0, it behaves the exact same, both Windows and OSX
  • I retested with all the available encodings, and all the png encodings work fine. raw RGB + zlib/lz4 has the bug. jpeg works fine.

How do I use xpra info|grep window?

comment:5 Changed 6 years ago by J. Max Mena

Okay, Alex showed me how to use it. I'll attach the relevant .txt.

Changed 6 years ago by J. Max Mena

Attachment: xprainfo.txt added

the file generated after running "xpra info | grep window > xprainfo.txt"

comment:6 Changed 6 years ago by Antoine Martin

Owner: changed from J. Max Mena to Antoine Martin
Status: newassigned

Thanks for the details, so this is not transparency or GL related, only raw RGB has this problem.
From the xpra info log, the tooltip window is (I'm only showing the most relevant bits):

window[34].window-type=('TOOLTIP',)
window[34].total_frames[rgb24]=1
window[34].total_pixels[rgb24]=4002
window[34].size=(174, 23)
window[34].override-redirect=True
window[34].has-alpha=True
window[34].encoding=h264
window[34].encoding.last_used=rgb24

Human readable summary: the window is a TOOLTIP override-redirect window and we only send a single pixel update (174x23=4002) which is using rgb24 because it is small enough, and not rgb32 because the client probably does not support it (win32 I assume). The global encoding seems to be set to h264, but we never create a video context for small transient windows like these.

And judging by the screenshot, it looks like the rgb24 data is being processed as if it was rgb32. This is strange but at least now I know where to look.

comment:7 Changed 6 years ago by Antoine Martin

Summary: pop-up alt img tags transparency issuessmall tooltip windows have transparency issues

Updated the bug title: it isn't with ALT tags, at least not in chrome, but with title tags (on both images and links).
A good page to test this is: links-testing.
I get the tooltip to show with chrome on tests: 13, 11, 10 (image only), 9, 8 (image only), 6, 5, 4, 3, 2

Changed 6 years ago by Antoine Martin

Attachment: test-link-title.html added

simplest html test case possible

comment:8 Changed 6 years ago by Antoine Martin

Fixed in r5262 (r5263 for v0.11.x branch) by not sending alpha: we tell the server we don't handle RGBA on win32 or OSX, this means we strip the alpha server side.
The reason why we didn't do this normally is that:

  • the bandwidth savings are tiny (since this is used for very small windows only)
  • all pixels are stored as 32bpp anyway, so the empty alpha gets re-added client side anyway

In the process of debugging, I cleaned up the GL codepath: r5261


I am keeping this ticket open because we should be able to handle RGBA pixels client side, even when we don't actually paint the alpha channel.
May be related to #521

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:9 Changed 6 years ago by alas

I am still seeing this issue on chrome (and lazarus) with osx client 0.12.0 r5531 and fedora 19 server 0.12.0 r 5531. Interestingly though, with firefox the tooltips are behaving as expected.

With chrome:

window[56].window-type=('TOOLTIP',)
window[56].total_frames[png]=1
window[56].total_pixels[png]=3772
window[56].size=(164, 23)
window[56].override-redirect=True
window[56].has-alpha=True
window[56].encoding=png
window[56].encoding.last_used=png

With firefox:

window[57].window-type=('TOOLTIP',)
window[57].total_frames[png]=1
window[57].total_pixels[png]=3744
window[57].size=(156, 24)
window[57].override-redirect=True
window[57].has-alpha=False
window[57].encoding=png
window[57].encoding.last_used=png

comment:10 Changed 6 years ago by Antoine Martin

Milestone: 0.12

As expected this is because of the alpha channel: firefox doesn't use alpha but chrome does (look for has-alpha).

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:11 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

Lots of fixes in this area: r5624, r5625, r5626, r5627 and some more in ticket:521#comment:4


So, the core issue was that we were converting BGRX to RGBX but still sending it as rgb24, and it needs to be rgb32 instead.


Most of the important fixes have been backported.

afarr: Feel free to close this ticket if everything works as expected, and if you have time please also check #521

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:12 Changed 6 years ago by alas

Bad news... with 0.12.0 r5692 osx client and 0.12.0 r5711 fedora 19 server I'm still seeing the buggy Alpha dsiplay on tooltips with chrome and lazarus. (I'll attach a screenshot.)

Are the fixes meant to fix that? Is there some way to override the alpha for tooltips?

The interesting (but unsurprising now) bits of xpra info | grep window:

window[26].has-alpha=True
window[26].window-type=('TOOLTIP',)
window[26].total_frames[png]=2
window[26].total_pixels[png]=12282
window[26].override-redirect=True
window[26].size=(267, 23)
window[26].override-redirect=True
window[26].encoding=png

Changed 6 years ago by alas

r5692 osx client chrome/lazarus tooltips still misbehaving

comment:13 Changed 6 years ago by Antoine Martin

Owner: changed from alas to Antoine Martin
Status: newassigned

AFAICT, this is a different bug with the exact same symptom, as it only occurs on OSX now. win32 is now fine and it wasn't before.

Which means that I will probably have to blacklist OSX for 32-bit RGB support. But I am now blocked by #529. Oh joy.

comment:14 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

Help... with r5760 on server and client, I just cannot reproduce this at all now. Which is odd because I haven't made any changes that should have fixed this (and I've just skimmed the list of changes since r5700), and I was seeing the problem 6 days ago!?

I also hacked my server to remove other encodings completely (to make sure only rgb would get used), tried other encodings, etc. No luck!?

Can you still reproduce?

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:15 Changed 6 years ago by Antoine Martin

Got it at last! (by trying various archived beta builds to narrow things down), counterintuitively this is a real bug that has been there for much longer but only came to the surface because packaging problems on OSX prevented the inclusion of PIL (Python Imaging Library) in the disk image (and recent build improvements fixed that - which made the bug disappear from view).
Without PIL, the code reverts to the slower GDK image loading code... which did not deal with rgb32 and assumed the data could only be rgb24... r5771 fixes that.

In order to test this alternative codepath, you need to run a client without PIL installed (for example by removing PIL from the installation image) or using the environment variable: XPRA_USE_PIL=0 xpra attach ...

Feel free to just test that things look good instead, and close this ticket.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:16 Changed 6 years ago by alas

Resolution: fixed
Status: newclosed

Ok, testing with XPRA_USE_PIL=0 the tooltips display as expected with all browsers (including with opengl=on).

Closing.

Note: See TracTickets for help on using tickets.