[Ext] BackTrack Tab History

[avada]

It still doesn't seem to be working for me at all when middle (or ctrl) clicking. Isn't possible to use the old v0.12 way for middle clicking and such? (Which works) And the new way only with left click?

Huh, that's disappointing. Was there anything in the log this time? I'm afraid it is not possible to use the old method mixed with the new, and chances are it would stop working soon enough anyway. I don't know why middle clicking results in a new content process when left clicking a link that opens a new tab does not, but I don't think that is behaviour that can be relied on. I have to assume that no frame script can share data with any other (even if at present they sometimes do).

I didn't see anything, just the no parent thing.
Huh. I didn't even notice that left click doesn't open a new content process, that's weird.

[AlexVallat]

I didn't see anything, just the no parent thing.
Huh. I didn't even notice that left click doesn't open a new content process, that's weird.

It occurs to me that perhaps the problem is the additional time it takes to go through the messaging system. If your system is slower than mine, it could explain the discrepancy if mine opens the new tab within the 500ms and yours takes slightly longer. Anyway, it's a bad idea in general to have that delay hard-coded so I've extracted it out into a pref: extensions.backtrack.parentClickTimeout, and upped the default value to 750ms. For this testing build I've also enabled a few more debugging statements, so you should see something like:

Code: Select all

BackTrack:Chrome:Setting Parent to Example Domain(4294967302)
BackTrack:Chrome:Assigning last parent Example Domain(4294967302) to (null) after 212ms
BackTrack:Chrome:Clearing Parent

(success)

or

Code: Select all

BackTrack:Chrome:Setting Parent to Example Domain(4294967302)
BackTrack:Chrome:Clearing Parent
BackTrack:Chrome:Assigning last parent null to (null) after 760ms
BackTrack:Chrome:No parent to copy history from. Last parent seen 1150ms ago

(failure due to new window taking longer to appear than timeout)

https://addons.mozilla.org/en-US/firefo ... ons/0.13b6

Edit: One caveat, it doesn't seem to like being upgrade-installed much, and doesn't create the default pref value. Not sure why, but restarting after installing will sort that out.

[avada]

I didn't see anything, just the no parent thing.
Huh. I didn't even notice that left click doesn't open a new content process, that's weird.

It occurs to me that perhaps the problem is the additional time it takes to go through the messaging system. If your system is slower than mine, it could explain the discrepancy if mine opens the new tab within the 500ms and yours takes slightly longer. Anyway, it's a bad idea in general to have that delay hard-coded so I've extracted it out into a pref: extensions.backtrack.parentClickTimeout, and upped the default value to 750ms. For this testing build I've also enabled a few more debugging statements, so you should see something like:

Code: Select all

BackTrack:Chrome:Setting Parent to Example Domain(4294967302)
BackTrack:Chrome:Assigning last parent Example Domain(4294967302) to (null) after 212ms
BackTrack:Chrome:Clearing Parent

(success)

or

Code: Select all

BackTrack:Chrome:Setting Parent to Example Domain(4294967302)
BackTrack:Chrome:Clearing Parent
BackTrack:Chrome:Assigning last parent null to (null) after 760ms
BackTrack:Chrome:No parent to copy history from. Last parent seen 1150ms ago

(failure due to new window taking longer to appear than timeout)

https://addons.mozilla.org/en-US/firefo ... ons/0.13b6

Edit: One caveat, it doesn't seem to like being upgrade-installed much, and doesn't create the default pref value. Not sure why, but restarting after installing will sort that out.

Okay I'll try. I'm gonna set it to something higher to begin with, just in case.

BTW. Does it make sense to have the extension restartless, when the newly installed extension won't work until I restart FF?

[avada]

This new version works fine for me so far. Just in case I increased the timeout to 1250.

Would it cause issues if set it to something high, such as a minute or so?

Edit: One caveat, it doesn't seem to like being upgrade-installed much, and doesn't create the default pref value. Not sure why, but restarting after installing will sort that out.

I think this is true to all versions of this addon. I had to restart every time I installed a new version. So the extension being restartless doesn't make sense to me.

[AlexVallat]

This new version works fine for me so far. Just in case I increased the timeout to 1250.

Would it cause issues if set it to something high, such as a minute or so?

Edit: One caveat, it doesn't seem to like being upgrade-installed much, and doesn't create the default pref value. Not sure why, but restarting after installing will sort that out.

I think this is true to all versions of this addon. I had to restart every time I installed a new version. So the extension being restartless doesn't make sense to me.

Did it also work fine at 750, or only once you increased it further? The issues caused by setting it very high is mis-association of a child tab. For example, if you clicked a link on a tab, and then clicked the New Tab or New Window button soon afterwards (within the timeout), that new tab would be erroneously considered a child of the first tab and have the history copied into it.

There's no obvious reason why it should need to be restarted when you upgrade. I'm pretty sure it doesn't when you install it from clean. I'll do some investigation and see if I can figure out why it's happening, or in the worst case, if I can somehow detect when it hasn't upgraded correctly and signal that a restart is required.

[avada]

Did it also work fine at 750, or only once you increased it further? The issues caused by setting it very high is mis-association of a child tab. For example, if you clicked a link on a tab, and then clicked the New Tab or New Window button soon afterwards (within the timeout), that new tab would be erroneously considered a child of the first tab and have the history copied into it.

As far as I can tell, it did.

If feels like relying on a timeout this is not very robust and could have many issues. For example, I just opened a bunch of links quickly from a duckduckgo search, and maybe half of the opened tabs had history. Actually it seems kind of a pattern if I open many tabs that only every other has history. Actually, if I'm fast enough the majority of tabs won't have history.

[AlexVallat]

If feels like relying on a timeout this is not very robust and could have many issues.

Oh, I agree, it is far from ideal. That's why I went to so much trouble to intercept link opening and tab creation in the original versions, so I could pipe the parent through directly. No relying on timing or previous foreground tab or anything. Sadly it looks like multiprocess is increasingly making that an unworkable approach. First for new windows, then, as you discovered, for new left-click tabs. Following the trend, I would not expect middle click new tabs to continue working in the future either.

I haven't completely given up on the timeout based system though, I think I can still improve it's robustness. If I measure the timestamp in the framescript and send that to the chrome script then that would eliminate the message passing time as a source of uncertainty. I can also have it do a calibration when installed, programmatically opening a new tab and measuring the time it takes to show. Worth a try, anyway.

[AlexVallat]

I've done some investigation on the restartless issue. Unfortunately due to quite a lot of aggressive caching (1051238, for example, but JSM modules too) allowing a clean upgrade appears impossible. I have added a notification popup to show that a restart is required though. It can't catch every case (like manually uninstalling and then re-installing), but it helps.

I've also added auto-calibration for the extensions.backtrack.parentClickTimeout - to trigger this if you have already set a value just reset it to 0 and restart. It opens a new window and times how long it takes to appear, then doubles that value for the pref.

Rather than clearing the parent value, I now check by timestamp whether too long has elapsed, and I take the timestamp as soon as the framescript is loaded. This should reduce the uncertainty, and better handle the case of opening a bunch of links quickly.

There might be more that can be done, but I'm starting to feel it might not be worth the bother as apparently this addon will be effectively dead by the end of 2017 (Firefox 57).

https://addons.mozilla.org/en-US/firefo ... ons/0.13b7

[avada]

I've done some investigation on the restartless issue. Unfortunately due to quite a lot of aggressive caching (1051238, for example, but JSM modules too) allowing a clean upgrade appears impossible. I have added a notification popup to show that a restart is required though. It can't catch every case (like manually uninstalling and then re-installing), but it helps.

I've also added auto-calibration for the extensions.backtrack.parentClickTimeout - to trigger this if you have already set a value just reset it to 0 and restart. It opens a new window and times how long it takes to appear, then doubles that value for the pref.

Rather than clearing the parent value, I now check by timestamp whether too long has elapsed, and I take the timestamp as soon as the framescript is loaded. This should reduce the uncertainty, and better handle the case of opening a bunch of links quickly.

There might be more that can be done, but I'm starting to feel it might not be worth the bother as apparently this addon will be effectively dead by the end of 2017 (Firefox 57).

https://addons.mozilla.org/en-US/firefo ... ons/0.13b7

Well, I reset the value, restarted FF. On restart a new window did open. (Don't think it's the best idea without explanation) and the value was set to 79608. Which might be excessive.

On second time it's 61172.

[AlexVallat]

Well, I reset the value, restarted FF. On restart a new window did open. (Don't think it's the best idea without explanation) and the value was set to 79608. Which might be excessive.

On second time it's 61172.

That's quite slow! Does 3-4 seconds to open a window sound normal for you? Opening a tab would be quicker so you can safely reduce the timeout if you only care about new tabs and not windows.

The calibration window does have a brief explanation in it, but I would expect it to auto close quickly anyway. It's a one-off operation, so hopefully not a big deal.

[avada]

Well, I reset the value, restarted FF. On restart a new window did open. (Don't think it's the best idea without explanation) and the value was set to 79608. Which might be excessive.

On second time it's 61172.

That's quite slow! Does 3-4 seconds to open a window sound normal for you?

Sounds about right.

[Str0ngwun]

There might be more that can be done, but I'm starting to feel it might not be worth the bother as apparently this addon will be effectively dead by the end of 2017 (Firefox 57).

Hi, Alex.
I start to hate Mozilla for it's decision to drop XUL support in favor of WebExtension APIs, but since Mozilla tries to sooth that pain down with claims that it will then improve and bring many more APIs to WebExtensions - I'm asking you - please, file a bug to bugzilla and request the APIs you think you need for this add-on to work nearly ideally with WebExtensions and e10s on Firefox.
I don't have much hope left, but still there's a chance they'll actually add those APIs.
Thanks in advance.
p.s.: came here to report middle click opening tabs without history, but read the recent posts and figured that I'll have to either downgrade or disable the add-on completely.
p.p.s: turned out I was on beta-channel of this add-on for some reason. Now that I've switched back to the release - everything is fine again.

[AlexVallat]

turned out I was on beta-channel of this add-on for some reason. Now that I've switched back to the release - everything is fine again.

Do you know which version of the add-on was failing middle-clicks for you? It would be really useful to know if it was the latest one: 0.13b8, as in my local testing this has now been 100% reliable at detecting middle-click opened tabs.

I very much doubt WebExtensions are going to expose the necessary internals to directly manipulate tab session history, and even less likely to be able to customise the menu drop-downs to enable the branched display. We'll see - if the time comes when Firefox will drop support for this extension then I will evaluate whether WebExtensions (at that time) provide anything approaching the flexibility required. If it's close, I can request tweaks to fill in any gaps that can't be worked around.

[avada]

Hi!

What are all these settings? There are now three timeout settings.
Roughly what values should I use? Automatically it came up with something like a minute plus, which doesn't seem like a good idea. I've had tabs with wrong history.

[AlexVallat]

Hi, extensions.backtrack.parentClickTimeout is now obsolete, and can safely be reset/removed.

extensions.backtrack.parentClickTimeoutTab is the used when opening a new tab.
extensions.backtrack.parentClickTimeoutWindow is the used when opening a new window.

If you only want to copy history when opening a link in a new tab, and not in a new window (which is my own personal preference), then there's now the option to control the two separately. There are two checkboxes in the addon options to control whether history should be copied on a new tab, or a new window, or both. (Or neither, I guess, but then there's not much point).

One minute sounds very long to me. You can always get it to recalculate an estimate by resetting the value and restarting. Or just manually set it to a value that suits you, depending on how slow Firefox is for you. Opening new windows is generally slower than new tabs, so I'd have that value be higher. On my machine I use 800ms for new tabs, and 1200ms for new windows, but Firefox runs quite quickly for me. If it generally takes longer than that for new windows or tabs to open for you, you will need a higher timeout.