Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

browser(firefox): properly initialize debugging pipe on windows #5514

Merged
merged 2 commits into from Feb 19, 2021

Conversation

aslushnikov
Copy link
Collaborator

@aslushnikov aslushnikov commented Feb 19, 2021

Context

Firefox on Windows has 2 launch modes:

  • default: a special "launcher process" is used to start browser as a
    sub-process
  • non-default: browser process starts right away

Firefox has a logic to detect how successful was the use of the
launcher process to do self-recovery when things go wrong. Namely:

  • when attempting to use launcher process, firefox records a timestamp
    of the attempt beginning
  • once the launcher process successfully launches browser sub-process,
    firefox records another timestamp of the completion

On a new launch, firefox checks what timestamps are present. If there's
a timestamp that signifies start of launcher process, but no successful
timestamp, it decides that last "launcher process" use was not
successful and falls back to launching browser right away.

Bug Investigation

When launching 2 firefox processes right away, the first process
uses attempts to use launcher process and records the first timestamp.

At the same time, the second instance sees the first timestamp and
doesn't see the second timestamp, and falls back to launching browser
right away. Our debugging pipe code, however, does not support
non-launcher-process code path.

Summary

This patch adds support for remote debugging pipe in case of
non-launcher-process startup.

Drive-by:

  • disable crashreporter altogether
  • remove stray dcheck that breaks firefox debug compilation
  • disable compilation of firefox update agent
  • do not use WIN32_DISTRIB flag unless doing full builds since
    it kills incremental compilation

References #4660

Firefox on Windows has 2 launch modes:
- default: a special "launcher process" is used to start browser as a
  sub-process
- non-default: browser process starts right away

Firefox has a logic to detect how successful was the use of the
launcher process to do self-recovery when things go wrong. Namely:
- when attempting to use launcher process, firefox records a timestamp
  of the attempt beginning
- once the launcher process successfully launches browser sub-process,
  firefox records another timestamp of the completion

On a new launch, firefox checks what timestamps are present. If there's
a timestamp that signifies start of launcher process, but no successful
timestamp, it decides that last "launcher process" use was not
successful and falls back to launching browser right away.

When launching 2 firefox processes right away, the first process
uses attempts to use launcher process and records the first timestamp.

At the same time, the second instance sees the first timestamp and
doesn't see the second timestamp, and falls back to launching browser
right away. Our debugging pipe code, however, does not support
non-launcher-process code path.

This patch adds support for remote debugging pipe in case of
non-launcher-process startup.

Drive-by:
- remove stray dcheck that breaks firefox debug compilation
- disable compilation of firefox update agent
- do not use WIN32_DISTRIB flag unless doing full builds since
  it kills incremental compilation

References microsoft#4660
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants