The WebRTC native code library supports 2 high-level approaches to window capture on Windows: capturing the screen & cropping it to the window bounds when some conditions are met, or attempting to capture just the window contents otherwise (e.g. if occluded by an unrelated window). Using the former approach conditionally with a fallback to the latter currently requires calling CroppingWindowCapturer::CreateCapturer (as Chromium-based browsers now do) rather than DesktopCapturer::CreateWindowCapturer (as Firefox currently does).
The contents of the affected app windows may be captured properly using the cropping approach (which is used on Win8+ when the captured window isn't occluded by unrelated windows).
This WebRTC bug tracks a potential change to capture the affected app windows properly in the fallback approach on Win8.1+: https://crbug.com/webrtc/10734 . That said, there may be some benefit to Firefox using the cropping approach when possible: it'd fix this issue in the interim in some cases, and may mitigate the perf impact of any fix for that bug (by making it less likely that the impacted path is used).
Note that the Firefox sharing indicator window at the top of the stream would prevent use of the cropping approach when the captured window is behind it unless it's allowed to be ignored / included in the captured frames by calling SetExcludedWindow. Chromium-based browsers appear to intend to allow the sharing notification bar to be included in the captured frames (as in the whole-screen capture case), but don't currently (details in https://crbug.com/973245 ). That said, they allow hiding the notification bar (with it still shown in the taskbar / window switcher), unlike the Firefox sharing indicator. Perhaps a means of hiding or unpinning the Firefox sharing indicator should be added, but that perhaps shouldn't block allowing it to be included in captured window frames in the meantime (such that the more-reliable / -performant cropping approach could be used).