'Firefox Home' page search option breaks when it's moved to a new window
Categories
(Toolkit :: Async Tooling, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox62 | --- | unaffected |
firefox63 | --- | wontfix |
firefox64 | --- | wontfix |
firefox65 | --- | wontfix |
firefox66 | --- | wontfix |
firefox67 | --- | fixed |
People
(Reporter: johnsonmcbig, Assigned: Felipe)
References
Details
(Keywords: regression)
Attachments
(1 file)
Reporter | ||
Comment 1•6 years ago
|
||
Updated•6 years ago
|
![]() |
||
Comment 2•6 years ago
|
||
![]() |
||
Comment 3•6 years ago
|
||
Updated•6 years ago
|
Comment 4•6 years ago
|
||
Updated•6 years ago
|
Comment 5•6 years ago
|
||
Updated•6 years ago
|
I don't think that felipe is working on these things these days, but he probably knows better than me who would.
Assignee | ||
Comment 7•6 years ago
|
||
Yeah, this is on me (very similar to bug 1499896). I don't think this is critical, since it requires opening a new tab and detaching it to a new window, but I'm planning on doing some work in this area this week and I'll make sure to fix this too.
Assignee | ||
Comment 8•6 years ago
|
||
The user-visible bug reported here is not happening anymore on the current Nightly because there were UI changes, but the underlying issue is still around and could affect other actors.
The problem is that the _dispatcher is assigned to the actor on the constructor and not in init(), but it was cleaned up on cleanup() (which is meant to be used as an init/cleanup pair), so it didn't get assigned again on the pageshow after the tab gets to the new window.
There really is no need to do this manual cleanup for the _dispatcher, so just removing it is the easiest.
Assignee | ||
Comment 9•6 years ago
|
||
Comment 10•6 years ago
|
||
This bug is marked as p1 and the patch looks minimal, Felipe, do you think that once landed you patch would be a potential candidate for uplifting to Beta? Thanks
Assignee | ||
Comment 11•6 years ago
|
||
(In reply to Pascal Chevrel:pascalc from comment #10)
This bug is marked as p1 and the patch looks minimal, Felipe, do you think
that once landed you patch would be a potential candidate for uplifting to
Beta? Thanks
Yep. I'll nominate it when it lands
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 12•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Comment 13•6 years ago
|
||
bugherder |
Comment 14•6 years ago
|
||
Is this something which should be considered for Beta backport or can it ride the trains?
Comment 15•6 years ago
|
||
bugherder |
Assignee | ||
Comment 16•6 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
Is this something which should be considered for Beta backport or can it
ride the trains?
If we're not seeing duplicates of this problem filed, or reports somewhere else on the web, I'd rather let this ride the trains..
Updated•6 years ago
|
Updated•6 years ago
|
Comment 17•6 years ago
|
||
Reproduced the issue on affected Nightly 64.0a1 (2018-09-08) (64-bit)
Now it is verified - fixed on the latest Firefox Beta 67.0b3 (64-bit) on Windows 10, Mac OS 10.13 and Ubuntu 16.04.
Description
•