Closed Bug 1657942 Opened 4 years ago Closed 6 months ago

Make WDBA Killswitch (`default-browser-agent debug-remote-disabled`) reveal status in more forms

Categories

(Toolkit :: Default Browser Agent, defect)

Desktop
Windows
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox80 --- wontfix
firefox81 --- affected

People

(Reporter: csasca, Unassigned)

References

Details

Attachments

(1 file)

Attached image No Output.png

Affected versions

  • Firefox 80.0b5
  • Firefox 81.0a1

Affected platforms

  • Windows 10 & 7

Steps to reproduce

  1. Install Firefox
  2. Launch Command Prompt
  3. Navigate to the location of firefox.exe (installation directory) in Comand Prompt
  4. Insert "default-browser-agent.exe debug-remote-disabled" string

Expected result

  • An output with details regarding wdba's task status is shown

Actual result

  • Nothing happens

Regression range

  • This is not a regression

Additional notes

  • The attachment shows the output comparation from the try build's output and 80.0b5
Blocks: 1636539

There's a lot going on here, so let me explain.

  1. The default-browser-agent.exe debug-remote-disabled functionality is happening; it's just that the output is not being displayed.

  2. To witness the output of debug-remote-disabled, snoop the registry under key Computer\HKEY_CURRENT_USER\Software\Mozilla\Firefox\Default Browser Agent. Inside that you'll find values with names like C:\Program Files\Firefox Nightly|DefaultAgentLastRemoteDisabled and binary values where 0 means "not disabled" and 1 means "disabled". You can delete this value and watch it be recreated to be confident things are being checked.

  3. To test the two cases, set the Firefox pref services.settings.server to:

  • prod (default), https://firefox.settings.services.mozilla.com/v1 for "not disabled"
  • stage, https://settings.stage.mozaws.net/v1 for "disabled"

Now, what's going on with the output. I think fundamentally this is about the MOZ_WINCONSOLE flag. We won't create a Windows console (to avoid disturbing the user when running in the background) but it looks like we aren't attaching to an existing one either. That's not what I expected. We can either fix that or we can send this output uniformly to the Windows event log where it can be seen in Event Viewer.

Simultaneously, we don't have quite as much Rust-level logging as would have answered this question: we don't give, say, the record body contents at debug level, or even print the remote disablement result at info level.

Finally, we don't exit with a disablement status from debug-remote-disabled.

I'll morph this ticket to address some of the latter bits, but I think using the registry value is enough to unblock testing. Catalin, can you try that and see where you get to? Thanks!

Flags: needinfo?(catalin.sasca)
Summary: WDBA Killswitch not giving task's status info in Comand Prompt → Make WDBA Killswitch (`default-browser-agent debug-remote-disabled`) reveal status in more forms
Has STR: --- → yes
Severity: normal → --
Flags: needinfo?(catalin.sasca)

No Severity has been set for this bug, Nick, could you please help?

Flags: needinfo?(nalexander)

Nick -> Kirk for setting severity here as Kirk's our triage person this month. (Triage calendar here)

Flags: needinfo?(nalexander) → needinfo?(ksteuber)
Severity: -- → S4
Flags: needinfo?(ksteuber)
Component: General → Default Browser Agent

The Default Agent kill switch has since been removed, obviating this issue.

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: