Infer reproducibility through browser logs
@GJFR is already working on this.
Since Aug 8, 2024.
Assessment
This issue has not been assessed yet.
Description
Ideally, we would be able to infer the reproducibility of a bug, not only through sent requests, but also through browser logs.
This way, console.log() calls would be logged to a file that is readable by the worker container in which the browser runs.
However, this doesn't seem to be straightforward to implement, nor robust for all experiment scenarios.
For example, Chrome (and Firefox?) will not log console output when in incognito mode.
Current status (not implemented):
- Chrome: logging works quite well if in
--headlessmode, up until +/- version 110. Using the new--headless=newfor versions after 110 also doesn't seem to be robust (e.g., browser crashes or doesn't start properly). - Firefox: I still haven't figured out how to include console output in browser logs.
For now, this idea will be put into the freezer. However, it would be convenient to have another way of inferring reproducibility, other than requests / traffic.
- Dominant language
- Python
- Stars
- 29
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from DistriNet/BugHog
-
Consider Nix for package management inside docker imagesMay be free again @GJFR claimed this 467 days ago, and no pull request is open. Openenhancement
-
Gantt Chart incompatibility with Brave BrowserMay be free again @GJFR claimed this 467 days ago, and no pull request is open. Openbug javascript
All issues in DistriNet/BugHog
Similar issues
-
json_params_matcher fails on falsy top-level JSON primitives (0, False, "")Possibly taken @mayureshsonawane17 claimed this today. OpenWaiting for: Product Owner
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 5 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
bojieli/ai-agent-book#1169 ·
Maintainers usually reply within 1 day
-
priority:low ready-for-dev
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
OpenHands/extensions#738 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
micronaut-projects/micronaut-core#13677 ·
Maintainers usually reply within 1 day