<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Comment 2

•

3 years ago

I can reproduce this. I took a look in a debugger to see what is causing the error and it looks like it happens as a result of this function call, which ensures that a registry key doesn't exist by deleting it. Most of the time it won't exist and then the function will log that it failed to remove the key, here.

Ideally we wouldn't be reporting an error when there isn't one, but this isn't really causing any harm nor is it indicating any actual failure. So let's keep this bug on file as an S4.

Severity: -- → S4

Updated

•

3 years ago

Component: Shell Integration → Default Browser Agent

Product: Firefox → Toolkit

Comment 3

•

3 years ago

I am currently using Firefox v114.0.1 [Build ID: 20230608214645; User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0] on a Win 10 Pro v22H2 Build 19045.2695 machine.

Multiple users, including myself, have reported this Event ID 2 error with Firefox v113.0.0 and higher in the Mozilla forum in new_aged2perfection's 14-May-2023 thread "Error in Event Viewer......Event 2 Firefox Default Browser Agent" at https://support.mozilla.org/bm/questions/1413304. The accepted solution for that thread is to change default-browser-agent.enabled to FALSE in the about:config advanced settings and/or DISABLE the Firefox Default Browser Agent scheduled task in the Windows Task Scheduler to prevent logging of this error.

Given that the cause of this error is already known (i.e., Firefox is unable to find a registry key at HKCU\Software\Mozilla\Firefox\Default Browser Agent\ when the scheduled task attempts to clean the registry), I would like to request that Mozilla mark this bug as Confirmed and increase the severity of this bug.

Comment 4

•

3 years ago

(In reply to L Macri from comment #3)

I would like to request that Mozilla mark this bug as Confirmed and increase the severity of this bug.

Could you explain why an entry in the Event Viewer is serious enough to warrant an increase in severity? I don't really understand how an error in the event viewer negatively effects anyone. It seems like a minor enough problem that our finite efforts would be better spent fixing other bugs that affect users in more tangible ways (of which we have a near limitless supply).

Status: UNCONFIRMED → NEW

Ever confirmed: true

Flags: needinfo?(ljmacri)

Comment 5

•

3 years ago

Hi Robin:

I was not suggesting that these errors would cause harm if ignored, but if users have already begun disabling the Firefox Default Browser Agent and/or its associated scheduled task to prevent logging of these errors then this defeats the purpose of running the task in the first place, which is to warn users if an outside agent has reconfigured their settings so that Firefox is no longer their default browser. I only discovered these Event ID 2 errors in my Event Viewer a few days ago and I suspect that more and more users will start disabling the Firefox Default Browser Agent as a workaround the longer this bug exists.

It sounds as if the bug fix would be relatively straight forward since you've already identified the code that generates this error. I assumed Mozilla would want to fix as many bugs as possible (even if some are "low-hanging fruit") before 05-Jul-2023 when all Windows 7 and 8.x users are automatically migrated to Firefox ESR v115.0.x extended support release and this browser becomes the final legacy version of Firefox that can be run on these older platforms.

Flags: needinfo?(ljmacri)

Comment 6

•

3 years ago

(In reply to L Macri from comment #5)

I was not suggesting that these errors would cause harm if ignored, but if users have already begun disabling the Firefox Default Browser Agent and/or its associated scheduled task to prevent logging of these errors then this defeats the purpose of running the task in the first place, which is to warn users if an outside agent has reconfigured their settings so that Firefox is no longer their default browser.

To be honest, I personally feel that users that are sufficiently technically-minded to use the event viewer, find an error, interpret the source, determine that the solution is to disable the WDBA, and then successfully do that are probably also sufficiently technically-minded to keep their preferred browser as the OS-registered default.

Comment 7

•

3 years ago

(In reply to Robin Steuber (they/them) [:bytesized] from comment #4)

(In reply to L Macri from comment #3)
Could you explain why an entry in the Event Viewer is serious enough to warrant an increase in severity? I don't really understand how an error in the event viewer negatively effects anyone. It seems like a minor enough problem that our finite efforts would be better spent fixing other bugs that affect users in more tangible ways (of which we have a near limitless supply).

I agree that this is the minor bug. But it doesn't mean that it should not be fixed.

The explanation is very simple. The best practice is to keep Event Viewer free from errors and warnings. In this case, the PC is healthy, and it's easy to notice an error looking at the log (red icon with exclamation point).

Another reason: the bug didn't exist in Firefox prior to v113. So this is the regression bug. The regression bugs ought to be fixed. Otherwise, the Firefox quality will rapidly decrease, while technical debt will rapidly increase. This is surely not the goal of FF team.

Finally, as far as I can see, the bug is simple. Thus it'll take only little effort to be fixed in forthcoming FF release.

Comment 8

•

3 years ago

(In reply to michael.miloslavsky from comment #7)

I agree that this is the minor bug. But it doesn't mean that it should not be fixed.

We would be happy to review and probably accept a patch if you submit one.

Comment 9

•

3 years ago

(In reply to Robin Steuber (they/them) [:bytesized] from comment #8)

We would be happy to review and probably accept a patch if you submit one.

I'd love to submit a patch, but I'm not a developer, unfortunately.

Comment 10

•

3 years ago

I would be happy to help you get started, if you'd like.

Comment 11

•

3 years ago

Thanks, but experienced developer will fix the bug much-much faster then a newbie. It's obvious.

As I understand, you are not going to fix this bug, at least soon.
OK, could you please clarify the downsides of workarounds suggested earlier (set the option default-browser-agent.enabled to false, and disable the Firefox Default Browser Agent scheduled task)?

Comment 12

•

3 years ago

(In reply to michael.miloslavsky from comment #11)

Thanks, but experienced developer will fix the bug much-much faster then a newbie. It's obvious.

I appreciate what you are trying to say here. But I would also like to point out that the reality is actually that it would, with very nearly 100% certainty, take you less time to rise to the programming level necessary to fix this than it would take for our team to fix every bug that has a higher user impact than "improperly logged error message". Like I said previously, bugs are filed faster than we are capable of fixing them and we have to pick where our impact will be the greatest.

OK, could you please clarify the downsides of workarounds suggested earlier (set the option default-browser-agent.enabled to false, and disable the Firefox Default Browser Agent scheduled task)?

I would like to point towards Mozilla's public explanation of why the Default Browser Agent exists but, sadly, I don't think that there is such a thing. There is some documentation of the component that I could point to. But it is, frankly, so far out-of-date as to not really be particularly accurate or helpful.

So instead I'll just say this: If you are confident in your ability to either (a) keep your default browser setting set to the browser that you want it to be, or (b) use the browser that you want to be using regardless of the default browser setting, then you do not need the Default Browser Agent and can safely turn it off.

BugBot [:suhaib / :marco]

Comment 13

•

3 years ago

(In reply to Robin Steuber (they/them) [:bytesized] from comment #12)

Thank you for comprehensive answer.

bugs are filed faster than we are capable of fixing them

This because the features implementation has priority over fixing the bugs.
I dream of the times when it turns vice versa (zero bug policy).

As for Default Browser Agent, I decided to turn it off by following the workaround suggested above.

Kestrel

Updated

•

2 years ago

status-firefox117: --- → wontfix

status-firefox118: --- → wontfix

status-firefox119: --- → fix-optional

status-firefox-esr102: --- → unaffected

status-firefox-esr115: --- → wontfix

Keywords: regression

Regressed by: 1826388

Comment 14

•

2 years ago

:nrishel, since you are the author of the regressor, bug 1826388, could you take a look?

For more information, please visit BugBot documentation.

Flags: needinfo?(nrishel)

Comment 15

•

2 years ago

This is an easy fix but given our existing priorities it would be better to use this as an onboarding bug for an intern, new hire, or new volunteer.

Flags: needinfo?(nrishel)

Updated

•

2 years ago

Priority: -- → P3

Updated

•

2 years ago

Keywords: good-first-bug

Donal Meehan [:dmeehan]

Updated

•

2 years ago

status-firefox119: fix-optional → wontfix

Comment 16

•

2 years ago

Hi Donal:

Thank you for the status update. Is there still a possibility that this bug will be classified as "fix-optional" for the upcoming Firefox 120 release?

I gather from Robin Stueber's Comment 2 at https://bugzilla.mozilla.org/show_bug.cgi?id=1834188#c2 that the function call causing this error had already been identified and would be relatively easy to fix, even if it is a lower priority bug that is not causing Firefox to crash.

Flags: needinfo?(dmeehan)

Donal Meehan [:dmeehan]

Comment 17

•

2 years ago

(In reply to L Macri from comment #16)

Hi Donal:

Thank you for the status update. Is there still a possibility that this bug will be classified as "fix-optional" for the upcoming Firefox 120 release?

I gather from Robin Stueber's Comment 2 at https://bugzilla.mozilla.org/show_bug.cgi?id=1834188#c2 that the function call causing this error had already been identified and would be relatively easy to fix, even if it is a lower priority bug that is not causing Firefox to crash.

Hi,
The release tracking status doesn't prevent anyone from working on the bug and landing a fix.
It only means that Release management is not tracking this for an upcoming release.
Fx120 is currently in beta, with the final beta week next week. This bug is triaged as P3/S4 and Comment 15 indicates the engineering team will not likely get to this in time for the Fx120 cycle.

Flags: needinfo?(dmeehan)

Comment 18

•

2 years ago

Now that the Default Agent has been migrated to a Firefox background task, we should really be using existing logging infrastructure instead of the event viewer which would obviate this issue.

Nick Alexander :nalexander [he/him]

Updated

•

2 years ago

See Also: → https://github.com/webcompat/web-bugs/issues/130780

Comment 19

•

2 years ago

Calin: there's no way this has anything to do with web compat; the WDBA isn't exposed to the web. The filed issue might be a Firefox bug, but it has nothing to do with web sites. It sounds like it might be interesting to the Win32k lockdown effort; consider talking to @gcp and team.

I'm morphing this ticket to track swapping out the logging system when the WDBA code is incorporated into Gecko. I have some interesting WIP on handling both in-and-out of Gecko in a try build somewhere that I'll try to post sometime soon. (Otherwise, ask me about it and I'll dig it out.)

Flags: needinfo?(ctanase)

Summary: Firefox Default Browser Agent Task failed with ID=2 in Windows Event Viewer → Replace WDBA event viewer logging with `MOZ_LOG` when running under Gecko

Nick Alexander :nalexander [he/him]

Comment 20

•

2 years ago

Nick, on webcompat we normally move or mark as duplicate the non-compat bug reports we receive. If I've mistakenly associated the bug report let me know.

Flags: needinfo?(ctanase)

Comment 21

•

2 years ago

(In reply to Calin Tanase from comment #20)

Nick, on webcompat we normally move or mark as duplicate the non-compat bug reports we receive. If I've mistakenly associated the bug report let me know.

That's what I'm saying: the webcompat GH ticket you link describes event viewer events but they're almost certainly not related to the event viewer events produced by the WDBA. (And the events in the GH ticket seem real, and are likely to be relevant to the Win32k lockdown effort, etc.)

Flags: needinfo?(ctanase)

Comment 22

•

2 years ago

(In reply to Nick Alexander from comment #21)

That's what I'm saying: the webcompat GH ticket you link describes event viewer events but they're almost certainly not related to the event viewer events produced by the WDBA. (And the events in the GH ticket seem real, and are likely to be relevant to the Win32k lockdown effort, etc.)

I've contacted @gcp, thanks.

Flags: needinfo?(ctanase)

Updated

•

2 years ago

See Also: https://github.com/webcompat/web-bugs/issues/130780 →

Comment 23

•

2 years ago

Attached image Win 10 Pro v22H2 Event Viewer Firefox Default Browser Agent Event ID 2 Stopped as of 20 Feb 2024.png — Details

Comment 24

•

2 years ago

Attached image Win 10 Pro v22H2 Task Scheduler Firefox Default Browser Agent Success 0x0 as of 20 Feb 2024.png — Details