Open Bug 594407 Opened 10 years ago Updated 3 years ago

Firefox windows are completely black when connecting to local session via RDP

Categories

(Core :: Graphics, defect, P3)

2.0 Branch
All
Windows 7
defect

Tracking

()

Tracking Status
blocking2.0 --- -

People

(Reporter: fehe, Assigned: bas.schouten)

References

Details

(Keywords: regression, Whiteboard: [unscoped][gfx-noted])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre ID:20100908040849

If you launch Minefield while logged in locally to a Windows XP system and then connect to the session via Remote Desktop, all the Minefield windows are completely black and the only recovery is to kill the Firefox process and relaunch in the Remote Desktop session.

I noticed this since hardware acceleration got flipped on by default.


Reproducible: Always

Steps to Reproduce:
1. Windows XP SP3 system required (real hardware -- no VM); ATI Graphics + Catalyst 10.8, if possible
2. Launch Minefield, while logged on locally to the system, and leave it running
3. Connect to the session via Remote Desktop
Keywords: regression
Version: unspecified → Trunk
This will be fixed once we have a software fallback approach.
This should definitely block final.
blocking2.0: --- → ?
I would be unhappy releasing with this bug, but if it slips to a dot release, I will cry only intermittently.
blocking2.0: ? → final+
Attached image screenshot
Not sure if that's related, but I noticed some incorrect color rendering of the chrome interface when using RDP with the "Desktop composition" option turned on.
One of the check-ins for today's nightly may have fixed this.  I'll know for sure, if I can't reproduce this in the next couple of days.
Correction: It could be any of the check-ins since Saturday's nightly.
Um.  Sorry for the bug spam.  IGNORE everything I wrote earlier today.  It's Monday, and I completely forgot that I disabled hardware acceleration. :-(
Status: UNCONFIRMED → NEW
Ever confirmed: true
Are you still seeing this, it should be fixed.
(In reply to comment #4)
> Created attachment 473172 [details]
> screenshot
> 
> Not sure if that's related, but I noticed some incorrect color rendering of the
> chrome interface when using RDP with the "Desktop composition" option turned
> on.

Well that's certainly ugly! I'm not seeing this though, could you create a separate bug?
(In reply to comment #8)
> Are you still seeing this, it should be fixed.

I won't know till tomorrow.  I will check then.
Checked.  Definitely NOT fixed in today's nightly build.
The continuation of this issue is that it's not just a problem when connected with RDP.  If I connect with RDP, the windows go blank.  If I then use that same Minefield session on the physical PC, the windows are still blank.

I also have an ATI graphics card on this PC.  Not sure if that's related, but I saw the original poster has one as well.
I have an nVidia card and don't seem to have any issues with Remote Desktop.

Direct2d and Direct3D (both 9 and 10) layers seem to be unaffected too, strangely.
Assignee: nobody → bas.schouten
Whiteboard: [unscoped]
Duplicate of this bug: 611572
blocking2.0: final+ → -
Depends on: 624088
With the Jan 12th nightly build, this got worse and has now happened even with hardware acceleration disabled.  Not sure which check-in is responsible.
Ignore comment 15.  Turns out the pref to enable/disable hardware acceleration got changed.  As such hardware acceleration got forced on me.
I would like to say that this was resolved for me in Firefox 4 Beta 9, but is back again in Firefox 4 Beta 10.  Use hardware acceleration if available is checked in firefox.  It will load up ok for about 3 seconds, then just locks up.  I can just get the preferences window open if i click fast enough.

Win7 x64, nvidia 260 card.
This is working for me tonight, using yesterday's (20110215) build.  Can anyone verify?
I'll try and remember to verify tomorrow.
This is most definitely NOT fixed.  Still reproducible with Feb 17, 2011 nightly.
I'm still seeing this in the 5.0 beta on Windows 7.
We should really find a machine (or try to build one) that reproduces this issue and fix it.
This is definitely NOT fixed. I have just reproduced it with the 5.0 final.

Windows XP SP3, nVidia 8600GT
We know it's not fixed, that's why the bug is still open.
I know is it open. It does not seem to be worked on either.
Where is the problem? As it seems to me the HW acceleration (graphic adapter info not refreshing) is the problem - after switching from RDP connection to local console, Firefox still has HW acceleration disabled and shows RDPDD as adapter driver. The other way it is probably the same (HW acceleration enabled with invalid nVidia adapter info), although I cannot confirm this as obviously I cannot see anything. Firefox 5.0 displays HW acceleration as "2/2 Direct3D 9". I am willing test any build, but unfortunately I am unable to tweak the source and build Firefox myself.
The problem is that Bas doesn't have a machine that he can reproduce this on ;-)
Duplicate of this bug: 679100
So, if I provide access to such machine, issue will be fixed?
Duplicate of this bug: 628959
Duplicate of this bug: 693047
Phoenix - yes! If your machine does this, we can do some remote debugging and fix this.
10.0a1 (2011-10-08), xp sp3

For me the window is not black, but paints whatever is placed on top of it, instead of its own contents.  Even though the menu bar is not visible the sub-menus do open when clicked in the right place.  The page context menu also shows and the window responds to keyboard shortcuts.

I can open a new window, which is not accelerated (GPU Accelerated Windows: 1/2 Direct3D 9) and works fine.  about:support still shows NVIDIA adapter info, should it be showing the RDP adapter?

Are you able to toggle acceleration for existing windows, as the session switches back and forth from local to RDP?
Duplicate of this bug: 693068
>Phoenix - yes! If your machine does this, we can do some remote debugging and fix this.
So, to who I must send access details? Bas didn't reply on two my e-mails
(In reply to Phoenix from comment #34)
> >Phoenix - yes! If your machine does this, we can do some remote debugging and fix this.
> So, to who I must send access details? Bas didn't reply on two my e-mails

These must've ended up in my spam filter! Try sending again and I'll keep an extra eye on my junkmail box!
I suppose that it will be difficult to resolve, because I can see that local ATI HAL Graphics is disabled through RDP session and if You relay on detection of HAL locally You don't know that screen is viewed by RDP and windows are not repainted refreshed. Although I believe that other browsers uses also HAL support and can handle it.
(In reply to Bas Schouten (:bas) from comment #35)
> These must've ended up in my spam filter! Try sending again and I'll keep an
> extra eye on my junkmail box!
Send another mail from satadm (at) gmail.com
I've been seeing this bug sporadically with modern versions of FF when RDP connecting to one Win7 x64 system. I've seen the problem with FF8 and earlier versions but I'm not sure when the issue started.

Symptoms are a transparent FF window that shows the underlying desktop or other application windows and no responsiveness to mouse clicks.  Keyboard shortcuts still work; it's possible to blindly close FF in an orderly fashion with alt-f4 or blindly operate TabMixPlus by keyboard to force a session save.

Closing and restarting FF through the RDP connection makes FF paint its windows properly, as does logging in to the host computer at the physical keyboard and monitor. Reconnecting via RDP makes no difference.

I haven't yet found a way to reproduce the issue on demand.
(In reply to ch-bugzilla from comment #38)
> I haven't yet found a way to reproduce the issue on demand.
Hardware acceleration is the key
Just a small update: I didn't receive a reply from bas on last letters, and see no activity on this bug. After new year I can't hold dedicate pc for this bug reproduction/debugging/fixing, if anybody of other developers want to take a minute and try to fix this regression, e-mail me, I'll provide access details and credentials.
Hi guys,

Sorry, don't want to cause any stir on the discussion. But I've this issue since FireFox 9.0.1 and still not fixed on FireFox 10.0.2. I'm on WinXP SP3 and using ATI Mobility FireFL V5700. When RDP from another WinXP SP3, the already open firefox frames are transparent, while some how I actually can still click the window control button (let say, minimize it) if I click in the right place (blindly guess where that particular button is supposed to be).

Any new on fixing this? Or workaround?

BR //Edo
Workaround - disable hardware acceleration, there is no other way, developers unwilling to work on this
OS: Windows XP → Windows 7
Hardware: x86 → All
This does not appear to be restricted to XP, the same issue arises with hardware acceleration and windows 7
Seems to be worse in FireFox 13.0, Windows 7 64-bit.

I've got one user who cannot use FireFox remotely any more because they get a transparent window 100% of the time. Here is what I saw:

1. Log off and log in did not fix the problem.
2. Rebooting the host machine did not fix the problem.
3. FireFox worked on my account (local on the host machine) at the same time it didn't work for the remote user.
4. I logged into the user's account using my laptop (right beside the host machine) and saw the exact same problem they reported (transparent window). I closed FireFox and logged off.
5. I logged into my own account (using the laptop) and FireFox worked fine.
6. I logged back into the user's account (using the laptop) and FireFox worked fine.
7. I asked the user to log into their account using Remote Desktop and the problem came back.
8. The user reported all other applications (Paint, Internet Explorer) worked fine.

So in summary:

* This issue is FireFox-specific.
* This issue is client-specific (some RDP clients trigger it, others do not).
* Once a "bad" RDP client opens FireFox it remains in a bad state until restarted under a "good" RDP client.
* This issue is a blocker, totally preventing the use of FireFox for some users.
* Disabling hardware acceleration worked around the problem.


Here is my GPU information:
Adapter Description: NVIDIA GeForce 8800 GT
Vendor ID: 0x10de
Device ID: 0x0611
Adapter RAM: 512
Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version: 8.17.13.142
Driver Date: 5-15-2012
Direct2D Enabled: true
DirectWrite Enabled: true (6.1.7601.17789)
ClearType Parameters: DISPLAY1 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 200 ] DISPLAY2 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 50 ]
WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce 8800 GT ) -- OpenGL ES 2.0 (ANGLE 1.0.0.963)
GPU Accelerated Windows: 1/1 Direct3D 10
AzureBackend: direct2d

I hope this helps.
Nothing improved over all the releases (since 4.0). I already gave up on Firefox, as I have encountered it every day. This is my last post.
Is there any way to detect when a remote user attaches to the display? If we could detect this at window-creation time, we could use non-accel layers. If they attach to an existing session, would it be possible to display an error at least, and have an option button to restart the windows/browser with non-accel layers?

It seems like layers fallback isn't coming any time soon, so we should at least fix this broken part, even if it's not in an ideal way.
Would not simply telling Firefox to redraw everything, when the attachment occurs, solve this?  Could the root cause be retained layers?

How does Chrome and IE9+ accomplishes this?
+1 for Comment #44.  I never noticed this until updating from Firefox 12 to 13, on Windows 7 64-bit.  I only observe the issues when using an RDP connection.  Disabling Hardware Acceleration resolves the issues.  I'd rather keep it on when I'm using the desktop locally, but remembering to switch it on and off is tedious.
The issue seems to be that Firefox 13 no longer disables hardware acceleration for Remote Desktop users. While there is a version of Remote desktop that can use hardware acceleration, it is far from the usual case. We need to either figure out a way to detect whether hardware acceleration will work on a given Remote Desktop connection, or we need to default turn off acceleration for those people. People who have Remote Desktop 7.1 can always turn it on if they really want it.
(In reply to Jeff Gilbert [:jgilbert] from comment #46)
> Is there any way to detect when a remote user attaches to the display? If we
> could detect this at window-creation time, we could use non-accel layers. If
> they attach to an existing session, would it be possible to display an error
> at least, and have an option button to restart the windows/browser with
> non-accel layers?
> 
> It seems like layers fallback isn't coming any time soon, so we should at
> least fix this broken part, even if it's not in an ideal way.

I'd always assumed we'd already had that, seeing as "Hardware Acceleration is disabled on this graphics card" would always be displayed in about:support until Firefox 13. This would not be displayed if you logged into the server directly. 

If we do not have this, detecting an RDP session is not that hard. All of the proposed answers on this page seem to work: http://stackoverflow.com/questions/973802/detecting-remote-desktop-connection
Duplicate of this bug: 769962
Just linked a dupe 769962 - same issue happening on Terminal Server on Firefox 13.0.1 for all users connected when a local admin on console logs in. The issue in my humble opinion seems that the detection of hardware acceleration seems to be workstation/server-based, rather than session-based.
Adding blocking bug 539356 based on comments here: https://groups.google.com/forum/#!topic/mozilla.dev.platform/UFndiSxW4rU
Blocks: dlbi
In case anyone is wondering, the specific comment prompting me to add blocking against DLBI is the the second paragraph of the first comment in the above linked forum post, which begins, "One class of performance regressions will not be completely fixable: we expect a performance regression for scrolling large pages with text over fixed backgrounds, with non-GPU-accelerated layers..."

That means that users would now have to endure a ongoing performance regression if they disable hardware acceleration to workaround this issue.
I'm also seeing this on 14.0.1 with Win7 x64 as RDP host and 32-bit Vista as client.

I was able to (at least temporarily) resolve it by closing Firefox, closing the RDP session, reopening the RDP session, then relaunching Firefox. However, I feel that it is not reasonable to expect most users to think of that workaround.

It's also a bit awkward that I would presumably have to restart Firefox yet again to regain hardware acceleration on the host machine when I next log in locally.
(In reply to IU from comment #54)
> That means that users would now have to endure a ongoing performance
> regression if they disable hardware acceleration to workaround this issue.

DLBI has an effect on the performance of non-GPU-composited widgets, but it's not significant wrt this bug.  Unsetting block.
No longer blocks: dlbi
Getting this issue on Win8 with FF 16.0.2.
Thanks!
I'm getting this issue on these machines:
Win7 64 bit
Win8 64 bit
RDP is Microsoft
Firefox on host is version 17.0.1
Guys,

I don't think the developers need to know what version to reproduce this under (that part is pretty clear). The question is how to reproducible is on demand. Last time I checked it was occurring 100% once the machine was in a "bad state" but it wasn't clear how to get it to go into this "bad state" in the first place from boot-up.

Second point: I've given up on Firefox because many important issues like this takes them years to fix. Even Google (which is also pretty bad at this) is doing a better job so I just bit the bullet and migrated to Chrome. Honestly, it's a better overall experience.

Firefox needs to shift more priority to bug fixing and less to add new bells and whistles (features). I love new features but not when the basic browsing experience is so painful...
(In reply to Gili from comment #59)
> Guys,
> 
> I don't think the developers need to know what version to reproduce this
> under (that part is pretty clear). The question is how to reproducible is on
> demand.
It is easily reproduced, I've provided remote access to such system for debug purposes to Bas, but, as I said year ago, "developers unwilling to work on this". Period.
The problem I reported back on Firefox 13 no longer seems to be an issue. In fact, I haven't seen this problem crop up since Firefox 14. Firefox now successfully detects both my real GPU and the fake one used for RDP, and blocks acceleration over RDP.

I do not fault the developers for balking on using someone else's computer to try to reproduce something. At that point, I'd honestly put it on you to create a hack to deal with the problem. There are several ways to write a Windows script that will check whether RDP is active. If you must have acceleration locally, then use such a script to disable it when Firefox is running over RDP. Otherwise, just disable hardware acceleration.

BTW, Chrome "fixes" this by using a (rather pricey) proprietary software GPU that kicks in if the real GPU fails. This is not an option for Mozilla, unless they've changed how they handle such things.
Terrell,

Your solution fails on two counts:

1. It assumes Firefox users are developers. Big fail here.
2. It questions the validity of a bug report because the developers are unable to reproduce it consistently. There is no denying that the bug exists because of the overwhelming number of users who have reported this problem. If the developers are not happy with the repro steps offered by the users, and the users don't have the technical ability to provide better repro steps, it falls upon the developers to push out more logs for collecting information on user installations. Maybe this will help you understand how to reproduce the problem on your end.

Big picture: bugs are the responsibility of developers, not users. We will do our best to help you reproduce the problem, but it is up to you to provide us with the necessary tools to do so.
Did some googling: should use WTSRegisterSessionNotification to register and receive WM_WTSSESSION_CHANGE messages.

Example of handling the WM_WTSSESSION_CHANGE message:
http://blogs.msdn.com/b/jgoldb/
(In reply to hardon from comment #63)
> Did some googling: should use WTSRegisterSessionNotification to register and
> receive WM_WTSSESSION_CHANGE messages.
> 
> Example of handling the WM_WTSSESSION_CHANGE message:
> http://blogs.msdn.com/b/jgoldb/

This could be an interesting idea, dropping out of acceleration when receiving this message, at least on Windows XP.
(In reply to Bas Schouten (:bas.schouten) from comment #64)
> (In reply to **** from comment #63)
> > Did some googling: should use WTSRegisterSessionNotification to register and
> > receive WM_WTSSESSION_CHANGE messages.
> > 
> > Example of handling the WM_WTSSESSION_CHANGE message:
> > http://blogs.msdn.com/b/jgoldb/
> 
> This could be an interesting idea, dropping out of acceleration when
> receiving this message, at least on Windows XP.

Yes, but I guess it depends on this bug: Bug #593027 - Disable HW acceleration option requires a restart
Is anyone working on this? It is still a problem with the latest Firefox beta version.
1) No
2) Yes
New repro (I think):
- Windows 7 x64 en-US, Firefox 34.0.5.5443 en-US on PC1
- Firefox running normally
- connect from PC2 to PC1 using mstsc (local LAN); Firefox running normally
- close mstsc from PC2
- when returning to PC1 (locked), when unlocked Firefox was running but not visible
All attempts to close or show it (including writing code to call ShowWindow(hwndMozillaWindowClass, SW_SHOW) or SetWindowPos with normal coordinates and SWP_SHOWWINDOW does nothing (SendMessage call appears hanging and eventually is bailing out with FALSE, GetLastError() is 0).
"layers.acceleration.disabled" is true on prefs.js. There is no user.js file.

Currently I am looking to Reset Firefox (after starting in Safe Mode and accepting cleanup - clicking Start in Safe Mode does nothing as regular mode), which was currently not respoding for some 5 minutes and eventually crashed itself. 
Looking in explorer it seems data has been cleaned up and no more disk activity; after the Reset crash the attempt to start it again leads to same behavior.
34 then 33 threads active, 20 user objects, 16 GDI objects (static). Firefox is not visible although it is running. Working set moving in 65.7-66.2MB, private memory stable on 38.5 MB.
Followup comment 68: noticed that audio service was hanging. After audio service fixed, Firefox started normally. Can be that Firefox attempted to load audio runtime and hanged forever on this one?
Still occurs on 35.0.1, windows 8.1. 

For a repro scenario that works for me 100% of the time, login local to a desktop, start a firefox session, lock the desktop, then login to that session from remote. The title bars/tabs on the firefox session will all be transparent, with no controls clickable on them. Other parts of the interface, like the address bar, or the menu that appears when you press alt, are rendering fine. 

Re-starting firefox on the RDP session it will render fine, and it does not appear to occur the other way around (session started in RDP, then logged in local).
(In reply to Kevin Dahl from comment #70)
> Still occurs on 35.0.1, windows 8.1. 
> 
> For a repro scenario that works for me 100% of the time, login local to a
> desktop, start a firefox session, lock the desktop, then login to that
> session from remote. The title bars/tabs on the firefox session will all be
> transparent, with no controls clickable on them. Other parts of the
> interface, like the address bar, or the menu that appears when you press
> alt, are rendering fine. 
> 
> Re-starting firefox on the RDP session it will render fine, and it does not
> appear to occur the other way around (session started in RDP, then logged in
> local).

Same behaviour here. You don't need to explicitly lock the local session btw, that happens automatically after a remote login.

And on a related-but-not-quite (and slightly cosmetic) note, the FF start menu icon through RDP appears on a white background instead of a transparent one.
(In reply to ibloodyhatespam from comment #71)
> (In reply to Kevin Dahl from comment #70)
> > Still occurs on 35.0.1, windows 8.1. 
> > 
> > For a repro scenario that works for me 100% of the time, login local to a
> > desktop, start a firefox session, lock the desktop, then login to that
> > session from remote. The title bars/tabs on the firefox session will all be
> > transparent, with no controls clickable on them. Other parts of the
> > interface, like the address bar, or the menu that appears when you press
> > alt, are rendering fine. 
> > 
> > Re-starting firefox on the RDP session it will render fine, and it does not
> > appear to occur the other way around (session started in RDP, then logged in
> > local).

What's required in order to fix this? I know it's not a critical issue, but nevertheless...

Same behavior as:
Bug 679100 - Firefox does not display in a Remote Desktop Connection session. 

I do (as the fellow above) run the latest Firefox 35.0.1 under Windows 8.1 64 bit

Thank you for considering a fix. Please!
(In reply to Phil from comment #72)
> What's required in order to fix this?
A developer, willing to fix this problem. Didn't see any of them here for years
It's not really high priority, for two reasons:

1. There's a workaround. Disable "Use Hardware Acceleration if Available" in the Advanced tab in the Options. 

2. It only seems to happen now if you started Firefox when it had hardware acceleration available, but then come back to it later in a context where HA doesn't work. All you have to do is restart Firefox, and it will work properly.

Basically, a fix would require either coming up with a way to detect if Firefox has gone black--something we haven't seen yet, or detecting when you log in from another location. Then it would have to check to see hardware acceleration is avaiable, and, if not, fall back. Since you pretty much need to restart Firefox to disable hardware acceleration, Firefox would just automatically restart itself, like in scenario 2.

Honestly, you're best off just using the workaround in Option 1. Just turn off hardware acceleration all the time. If you're unwilling to do that, you're just going to have to restart Firefox when you log in under Remote Desktop.


(Note, Chrome won't work at all in this situation, unless you add a special parameter to the shortcut. At least Firefox works.)
Another potential workaround is to use VNC instead of RDP. I've had better luck that way at least.
(In reply to Terrell Kelley from comment #74)
> (Note, Chrome won't work at all in this situation, unless you add a special
> parameter to the shortcut. At least Firefox works.)
Well, Chrome works without problems. Started with HW acceleration, falls back if HW not available after connecting through RDP.
I don't know what your configuration is, but it sure doesn't work for me. Chrome WILL NOT fallback at all. The only way to shut off GPU acceleration is to use a command line option. I cannot run Chrome over RDP without explicitly disabling hardware acceleration.

This is Windows 7 Professional, BTW: the one that doesn't provide hardware acceleration for RDP. Running it on Windows 7 Ultimate or any version of Windows 8 is a whole different story. But, in that configuration, Firefox should not have any problem with hardware acceleration. If you can run Aero, you should also be able to run Firefox with hardware acceleration.

If you can't, then there's something else going wrong.
(In reply to Terrell Kelley from comment #74)
> It's not really high priority, for two reasons:
> 
> 1. There's a workaround. Disable "Use Hardware Acceleration if Available" in
> the Advanced tab in the Options. 
> 
> 2. It only seems to happen now if you started Firefox when it had hardware
> acceleration available, but then come back to it later in a context where HA
> doesn't work. All you have to do is restart Firefox, and it will work
> properly.
> 
> Basically, a fix would require either coming up with a way to detect if
> Firefox has gone black--something we haven't seen yet, or detecting when you
> log in from another location. Then it would have to check to see hardware
> acceleration is available, and, if not, fall back. Since you pretty much need
> to restart Firefox to disable hardware acceleration, Firefox would just
> automatically restart itself, like in scenario 2.
> 
> Honestly, you're best off just using the workaround in Option 1. Just turn
> off hardware acceleration all the time. If you're unwilling to do that,
> you're just going to have to restart Firefox when you log in under Remote
> Desktop.
> 
> 
> (Note, Chrome won't work at all in this situation, unless you add a special
> parameter to the shortcut. At least Firefox works.)

Good to know.
Thank you for the explanation!
(In reply to benshadwick from comment #75)
> Another potential workaround is to use VNC instead of RDP.
You know the differences between these two types of remoting, do you? Bandwidth requirements, etc? vnc is a poor man's choice under Windows
(In reply to Terrell Kelley from comment #74)
> It's not really high priority, for two reasons:
> 
> 1. There's a workaround. Disable "Use Hardware Acceleration if Available" in
> the Advanced tab in the Options. 

I suspect that this workaround will have other implications - firefox wouldn't default to hardware acceleration were there not some net benefit from it. I'm willing to give it a go though.

I think I did notice one other possible workaround today, but I haven't had time to fully test it. I had minimized my firefox session before I logged in from remote, and I did not have the issue when I logged in over RDP just now. If all it takes is minimizing the browser before locking, then that's definitely workable. 
 
> 2. It only seems to happen now if you started Firefox when it had hardware
> acceleration available, but then come back to it later in a context where HA
> doesn't work. All you have to do is restart Firefox, and it will work
> properly.

That may not seem like a big deal, but I tend to leave firefox open because there's something that I'm not yet finished with in those tabs. IPython notebooks or documentation, half written emails, etc. I flip back and forth between local and remote to my workstation all day long, and re-starting firefox all the time is really a no-go for me.
(In reply to Terrell Kelley from comment #74)
> It's not really high priority, for two reasons:

1. There's a workaround.
> Disable "Use Hardware Acceleration if Available" in the Advanced tab in the
> Options. 

But you cant change options because you dont have access to the options. All that you have is a black screen. And rpd connection means that you dont have physical access to the PC. In fact I lost access to my favorites, password, history until manually change this option directly, not over rpd.
(In reply to Stawros from comment #81)
> (In reply to Terrell Kelley from comment #74)
> > It's not really high priority, for two reasons:
> 
> 1. There's a workaround.
> > Disable "Use Hardware Acceleration if Available" in the Advanced tab in the
> > Options. 
> 
> But you cant change options because you dont have access to the options. All
> that you have is a black screen. And rpd connection means that you dont have
> physical access to the PC. In fact I lost access to my favorites, password,
> history until manually change this option directly, not over rpd.

You can. You just need to start Firefox in Safe Mode by holding Shift down while you try to start it. You'll have access to all the options from there.
(In reply to Terrell Kelley from comment #82)
> (In reply to Stawros from comment #81)
> > (In reply to Terrell Kelley from comment #74)
> > > It's not really high priority, for two reasons:
> > 
> > 1. There's a workaround.
> > > Disable "Use Hardware Acceleration if Available" in the Advanced tab in the
> > > Options. 
> > 
> > But you cant change options because you dont have access to the options. All
> > that you have is a black screen. And rpd connection means that you dont have
> > physical access to the PC. In fact I lost access to my favorites, password,
> > history until manually change this option directly, not over rpd.
> 
> You can. You just need to start Firefox in Safe Mode by holding Shift down
> while you try to start it. You'll have access to all the options from there.

It's hard to click anywhere, when all you see is a black screen. Have you ever experienced this bug? You connect via RDP and you see a black rectangle - you can't even start the task manager to kill Firefox, you can do nothing.
(In reply to Piotrek Gliźniewicz from comment #83)
> (In reply to Terrell Kelley from comment #82)
> > (In reply to Stawros from comment #81)
> > > (In reply to Terrell Kelley from comment #74)
> > > > It's not really high priority, for two reasons:
> > > 
> > > 1. There's a workaround.
> > > > Disable "Use Hardware Acceleration if Available" in the Advanced tab in the
> > > > Options. 
> > > 
> > > But you cant change options because you dont have access to the options. All
> > > that you have is a black screen. And rpd connection means that you dont have
> > > physical access to the PC. In fact I lost access to my favorites, password,
> > > history until manually change this option directly, not over rpd.
> > 
> > You can. You just need to start Firefox in Safe Mode by holding Shift down
> > while you try to start it. You'll have access to all the options from there.
> 
> It's hard to click anywhere, when all you see is a black screen. Have you
> ever experienced this bug? You connect via RDP and you see a black rectangle
> - you can't even start the task manager to kill Firefox, you can do nothing.

I suspect this issue may be causing RDP sessions to become entirely unusable - I have had a persisting problem where I'll connect to an RDP session where the browser was left open and only get a black screen. It happens about once a month, but I would quite regularly have the issue with the black/unusable tabs. I'm switching to Chrome to see if the black screen issue still occurs.
If the problem is that Firefox is open when you start RDP, then you need to close it first. Press Alt-F4 like you would to close anything. You may then need to press Enter if a dialog pops up that you can't see. Then, once Firefox completely shuts down, you can open in Safe Mode by following the instructions I gave above, and then disabling hardware acceleration.

For subsequent use, either always be sure to close Firefox when going from local to remote, or, if that's not practical, turn off Hardware acceleration and leave it off.

As for Chrome, my experience is that you will have to manually disable hardware acceleration to even get it to launch properly in RDP. Otherwise, you'll get an invisible window.
(In reply to Terrell Kelley from comment #85)
> If the problem is that Firefox is open when you start RDP, then you need to
> close it first. Press Alt-F4 like you would to close anything. You may then
> need to press Enter if a dialog pops up that you can't see. Then, once
> Firefox completely shuts down, you can open in Safe Mode by following the
> instructions I gave above, and then disabling hardware acceleration.
> 
> For subsequent use, either always be sure to close Firefox when going from
> local to remote, or, if that's not practical, turn off Hardware acceleration
> and leave it off.
> 
> As for Chrome, my experience is that you will have to manually disable
> hardware acceleration to even get it to launch properly in RDP. Otherwise,
> you'll get an invisible window.

As the person in comment 83 mentioned, when this black screen login issue occurs you cannot close anything - you cannot interact with the desktop in any way whatsoever, because there is just black. So far as I have found not even keyboard shortcuts to close any open applications work, i.e. it appears you never correctly connect to the desktop session to interact with it. When this occurs, the only solution I have found is forcing a reboot from remote, or having a colleague reboot my computer (and these reboots generally result in loss of work).

Now I don't really know if it's firefox causing this or not, I'm just looking to do some experiments to find a more stable work setup. I can't easily re-create the problem, so I have to just go on empirical evidence gathered over time. The issue generally happens at least once a month, so I'll stick it out for a couple of months and see.

As for the solutions - 

Always closing the browser isn't really practical for me, as I don't know when I am going to connect from remote and when I am not, and I often have long running ipython notebook processes open. Technically the state would be saved in the ipython process so I could close it and re-connect from a different session, but I'd rather test how Chrome before going this route.

Disabling the hardware acceleration permanently also isn't really an option, as much of what I'm doing in the ipython notebook is going to result in dataviz that would likely take advantage of those capabilities (this is just an assumption, though).

So far with Chrome I haven't had any such issues, it launches just fine with hardware acceleration enabled, and a session that is launched local appears to work exactly the same whether I reconnect from remote, or launch a new session from remote. The tabs all render fine as well, so it has that going for it I suppose.

Anyways, we'll see.
Whiteboard: [unscoped] → [unscoped][gfx-noted]
Version: Trunk → 2.0 Branch
You need to log in before you can comment on or make changes to this bug.