Disable downgrade checks
Categories
(Testing :: mozregression, task, P1)
Tracking
(Not tracked)
People
(Reporter: mossop, Assigned: bugzilla)
References
Details
Attachments
(2 files)
| Assignee | ||
Comment 2•6 years ago
|
||
I don't think it's reasonable to call this an enhancement at this point; mozregression doesn't work across downgraded versions anymore.
| Assignee | ||
Comment 3•6 years ago
|
||
| Assignee | ||
Updated•6 years ago
|
| Reporter | ||
Comment 4•6 years ago
|
||
I'd be interested to know what cases exists that weren't already fixed by https://github.com/mozilla/mozregression/pull/510
Updated•6 years ago
|
Comment 5•6 years ago
|
||
(In reply to Dave Townsend [:mossop] (he/him) from comment #4)
I'd be interested to know what cases exists that weren't already fixed by https://github.com/mozilla/mozregression/pull/510
If there's an alternate way of solving this bug, please let me know! I would prefer not to pass args in mozregression. For now, I've merged Aaron's pr (with some minor modifications) and will do up a new release shortly.
| Reporter | ||
Comment 6•6 years ago
|
||
What I was saying is that https://github.com/mozilla/mozregression/pull/510 was already making mozregression pass --allow-downgrade arguments to Firefox in what I thought were the necessary cases. Just wondering what cases it missed. If https://github.com/mozilla/mozregression/pull/534 is making us always pass --allow-downgrade to Firefox then https://github.com/mozilla/mozregression/pull/510 is probably no longer necessary.
Comment 7•6 years ago
|
||
(In reply to Dave Townsend [:mossop] (he/him) from comment #6)
What I was saying is that https://github.com/mozilla/mozregression/pull/510 was already making mozregression pass --allow-downgrade arguments to Firefox in what I thought were the necessary cases. Just wondering what cases it missed. If https://github.com/mozilla/mozregression/pull/534 is making us always pass --allow-downgrade to Firefox then https://github.com/mozilla/mozregression/pull/510 is probably no longer necessary.
Geez, yeah, that does look like it's trying to do the same thing! I should have grepped through the codebase before landing the latest PR, my recollection was that the earlier changes to make this work were just around preferences.
I didn't test, but I suspect the approach in #510 might fail if you're passing a URL to the application. That was certainly a problem with #534 until I made some adjustments. I think the solution there is a little more robust, so I'll look into reverting #510 in a bit.
Comment 8•6 years ago
|
||
Comment 9•6 years ago
|
||
Updated•6 years ago
|
Comment 11•6 years ago
|
||
Based on bug 1550806 comment 3 it looks like I was too quick to assume what the problem was and dupe. I think we should actually revert PR#534 seeing as it didn't help with what it was meant to (and might have actually broken URL passing, for me at least).
Description
•