Browser toolbox breakpoints are not respected when removed in Form Autofill components
Categories
(DevTools :: Debugger, defect, P2)
Tracking
(firefox99 fixed)
Tracking | Status | |
---|---|---|
firefox99 | --- | fixed |
People
(Reporter: tgiles, Assigned: ochameau)
References
(Blocks 3 open bugs)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
STR:
- Enable credit card autofill by setting "extensions.formautofill.available" to true. Edit: you probably want to update "extensions.formautofill.creditCards.supported" to "on" instead of the previous pref.
- Restart browser so pref can take effect
- Add credit card to "about:preferences" -> Saved Credit Cards. I just use a number off paypal's test list
- Navigate to one of the form fill test pages
- Open browser toolbox and set a breakpoint in FormAutofillHandler at line 210, or the first line under "matchSelectOptions". Permalink for reference.
- Click a field on the test page and notice the breakpoint is triggered
- Remove breakpoint
- Click a field on the test page and notice the breakpoint is still triggered
Expected results:
Breakpoint is not triggered after removal
Actual results:
Breakpoint is triggered after removal. You must restart the browser toolbox in order to remove the reference to the breakpoint.
I have no idea why this is happening, and I verified this doesn't happen in the password manager code (which is the other part of the codebase that I'm familiar with). I'm guessing this is something to do with how the form autofill component is structured but I'm not sure.
Reporter | ||
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Thanks for reporting! I added some update notes to the STR
(In reply to Tim Giles [:tgiles] from comment #0)
STR:
- Enable credit card autofill by setting "extensions.formautofill.available" to true.
This would probably be extensions.formautofill.available
to "on"
.
- Open browser toolbox and set a breakpoint in FormAutofillHandler at line 210, or the first line under "matchSelectOptions". Permalink for reference.
If the FormAutofillHandler.jsm is not available, click in a field on the test page first
I have no idea why this is happening, and I verified this doesn't happen in the password manager code (which is the other part of the codebase that I'm familiar with). I'm guessing this is something to do with how the form autofill component is structured but I'm not sure.
We have been having random issues with removed breakpoints still triggering.
Thanks for the STR.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Chasing zombie breakpoints seems important
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
This probably had many side effects in the browser toolbox when debugging content processes.
But the main one was about not properly unregistering breakpoints when removing/disabling it.
This is only specific to content process targets, so this is only impacting the browser toolbox.
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
Sorry for the delay and thanks Tim for the STR.
This helped undercover a significant issue around content process debugging.
I hope things will be much better after this one fix and we should keep polishing the debugger this quarter.
Try run for this patch:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=27c8d03660a5acd96af844b02b655e9806889dc1
Updated•3 years ago
|
Comment 6•3 years ago
|
||
bugherder |
Assignee | ||
Comment 7•3 years ago
|
||
Hi Tim
Could you confirm we fixed the issues you were having?
Your STR was actually super useful.
Let us know if you have any other issues with the debugger.
Reporter | ||
Comment 8•3 years ago
|
||
Just confirmed the issue is fixed for me on the latest pull of central. Thank you for resolving this, you've already made my week great! I've had so much frustration with our form autofill debugging due to these zombie breakpoints and now things appear to behave as expected.
Description
•