Assuming Australis hits stable when we are dealing with a TorBrowser based on Fx 31 we should streamline the Torbutton appearance in the toolbar. There are some rough edges due to the new UI paradigm.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
This is also an opportunity to review the Torbutton UI and think about how to streamline it and make it better. Related bugs: #10632 (moved), #11175 (moved), #12514 (moved) (and others, I am sure)
Ideally, if these are all the changes we need for FF31esr, this new Torbutton would still work on FF24esr, so we don't have to make a separate branch for the 31esr series.
Is it possible to wrap that HUDService import in a try/catch or version check (as is done in torbutton_init())?
I've updated the branch to handle both ESR24 and ESR31 cases. I'm still working on it, in part because there's a weird bug with the popup menu where it only pops up on the second run of TBB.
In the medium term, it might be nice to fully adapt to the Australis style of popup panel. That probably means breaking backward compatibility, so perhaps that should wait until the ESR24 version is retired.
Ideally, if these are all the changes we need for FF31esr, this new Torbutton would still work on FF24esr, so we don't have to make a separate branch for the 31esr series.
#10716 (moved) makes the ESR 31 Torbutton incompatible with the ESR 24 one unless we do some version detection within Torbutton and or just ship both the old and the new logic (as the current patch does), a thing I'd like to avoid.
Ideally, if these are all the changes we need for FF31esr, this new Torbutton would still work on FF24esr, so we don't have to make a separate branch for the 31esr series.
#10716 (moved) makes the ESR 31 Torbutton incompatible with the ESR 24 one unless we do some version detection within Torbutton and or just ship both the old and the new logic (as the current patch does), a thing I'd like to avoid.
I can see good arguments both for and against using version detection. We could use version detection during the transition period bewteen ESRs and then delete code for ESR 24 after it's retired. What do you think? I'll post patches here for review once we've decided which way to go.
As this is affects only a short transition period and no huge changes seem to be involved I think having just one branch + version detection might be less overhead, yes.