Temporary-containers: On Firefox Nightly, new tabs lose the first character typed

[escapewindow]

• Temporary Containers Version: 0.93, updated yesterday (April 1)
• Firefox Version: 68.0a1 (2019-04-02) revision
• Operating System + Version: MacOS 10.14.3
• Non-default Options/Preferences in Temporary Containers:
  
  
  
  • automatic mode on
  
  
  • some per-site configs, but this happens before that
  
  
• Other installed Add-ons + Version:

Firefox Multi-Account Containers 6.1.0 true @testpilot-containers
Forest: stay focused, be present 3.9.5 true @forest-firefox-addon
LastPass: Free Password Manager 4.26.0.4 true [email protected]
MyQOnly 0.7.1 true [email protected]
Switch Container 0.8 true {c580e2d6-885a-4cb9-af49-59b3b48350e9}
Tabby - Window and Tab Manager 1.1.6 true [email protected]
Temporary Containers 0.93 true {c607c8df-14a7-4f28-894f-29e8722976af}
Tree Style Tab 3.0.4 true [email protected]
wxIF 0.2 true {8b3ee44a-0805-4c2c-acef-15aab34fbd20}

Actual behavior

Open new tab, start typing:

cmd-T URL

Instead of seeing URL in the address bar, see RL (first character is dropped)

Expected behavior

When I type a url into a new tab, it should stay as typed.

Steps to reproduce

1. cmd-T (open new tab)
2. start typing url, e.g. about:support
3. note that the url is bout:support
4. turn off temporary containers
5. repeat steps 1-2, then note that the url is about:support

Notes

The debugging instructions don't seem to work: about:debugging doesn't have an enable debugging checkbox

// debug log from apr4
log.DEBUG=true
true
Error: Could not establish connection. Receiving end does not exist. 2 background.js:76:21
Error: Could not establish connection. Receiving end does not exist. 2 background.js:76:21
Error: Invalid tab ID: 226 ExtensionUtils.jsm
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. 2 background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Invalid tab ID: 228 ExtensionUtils.jsm
Error: Could not establish connection. Receiving end does not exist. 2 background.js:76:21
Error: Could not establish connection. Receiving end does not exist. 2 background.js:76:21
Error: Could not establish connection. Receiving end does not exist. 2 background.js:76:21
Error: Invalid tab ID: 229 ExtensionUtils.jsm
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. 2 background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. 2 background.js:76:21
Error: Could not establish connection. Receiving end does not exist. 2 background.js:76:21
Error: Invalid tab ID: 232 ExtensionUtils.jsm
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21
Error: Could not establish connection. Receiving end does not exist. background.js:76:21

[stoically]

The default behavior when opening new tabs (with Cmd+T or clicking the new tab icon) in automatic mode is that a tab in no container is opened and then is reopened in a temporary container. That's unfortunately the only way to do it, since it's not possible to overwrite default shortcuts. So if the reopening is slow, you actually start typing in the first tab, which then gets replaced with the TC, hence what you typed in the first tab is lost.

A workaround is to configure the "Don't reopen new tabs" automatic mode advanced preference in TC - or use the Alt+C shortcut.

Hope that helps.

[qazip]

@stoically, it used to be ok until the last version of temporary-containers though. The flicker is longer now (it takes longer to create a new container). I've been using temporary-containers for many months now and it never bothered me, until now.

[stoically]

@qazip Do you by chance have "Blank page" for new tabs configured in Firefox? If so, then only a recent fix #146 made it so that about:blank tabs are reopened in a TC - before that it was actually behaving like the "Don't reopen new tabs" preference, so you could configure that to get the old behavior back. For about:newtab ("Firefox Home (Default)") nothing changed.

[qazip]

@stoically, I am not sure what you mean. My new tab is indeed completely blank (I open with ctrl+T). However, it has always opened a new container. I know this because I noticed the counter increasing and also the flicker was always there, it is just that now it is more obvious.

[stoically]

I meant in the Firefox options under "Home" the "New tabs" setting. But since TCs reopened for you, that's not relevant here.

So, I looked into it and it turns out something changed between Firefox 65 and 66. With 65 tabs.onCreated fired with the url already set to about:newtab, and so TC was able to instantly reopen. With 66 onCreated doesn't fire any longer with the correct url set, but only a bit later tabs.onUpdated fires with url as changeInfo, which explains that you now see more of a delay. I'll report to Bugzilla and see if they're willing to fix that.

[qazip]

Nice. Please leave a link to the report here, once you do it. Thank you!

[stoically]

Let's see how it turns out: https://bugzilla.mozilla.org/show_bug.cgi?id=1541847

[stoically]

Welp, decided to test with Beta 67.0b3 and Nightly 68.0a1 (2019-04-04), and there onCreated behaves like expected again. So it seems we just have to wait for the Firefox 67 release.

[stoically]

@qazip It turned out that I didn't test thoroughly enough, it seems that Firefox 66 also fires onCreated as expected with about:newtab - but I did observe the "bug" behavior with an old profile on Dev Edition 67.0b7 - creating a new profile "fixed" it. (I'm using quotes because it actually is expected to happen sometimes, but shouldn't most of the time)

Could you provide which version of Firefox you're using and a debug log of opening a new tab? That would be helpful to see what's actually going on in your case.

@escapewindow On Nightly the debugging tab has changed: You'd need to open about:debugging#/runtime/this-firefox, tick the Enable extension debugging. checkbox and click Inspect to the right of Temporary Containers. I've updated the debug log wiki entry to include instructions for Firefox 68.

[escapewindow]

Done, added my debug log to the initial comment. The first Invalid Tab lines all worked (cmd-T twe -> tweetdeck.twitter.com). The very last Invalid Tab line was where I was able to reproduce the problem (cmd-T twe -> web.archive.org, because the t was dropped).

However, yes, I'm using a blank tab as my new tab. Since I'm not worried about a blank tab setting cookies, once I found the Don't reopen New Tabs in Temporary Containers but instead on navigation option, I selected that. That has resolved this issue for me.

[qazip]

I am using firefox 66.0.2 on Arch. Hopefully the logs I copied are enough, I only copied stuff that appeared after opening a new tab.

firefox_debug_log.txt

[stoically]

@escapewindow Thanks, but those logs are unrelated to TC. Maybe you clicked the wrong Inspect or inside the Developer Tools in the console there was no Logs selected (blue background for the button). But since you have blank page configured it is expected to happen, since about:blank reopens tabs slightly later than about:newtab, because new about:blank tabs can also start loading an actual webpage, so TC has to wait for the onUpdated event which fires some ms later. Glad Don't reopen works for you.

@qazip Thanks. As I can see from the logs you actually have "Blank page" configured in the Firefox Options under "Home" for "New tabs". So the same as described above applies to you. You can configure Don't reopen in the advanced automatic mode TC preferences (which behaves the same as before where Blank pages weren't reopened), or configure "Firefox Home" under "Home" > "New tabs" (and untick all the "Firefox Home Content" checkboxes to essentially also have a Blank page).

[qazip]

I changed to Firefox home but I still have the same problem. Do you want me to send you new logs?

[stoically]

A log would be interesting to see whether onCreated fires correctly with about:newtab in your case, yes.

[qazip]

I don't remember if I did the logs for the right extension (sorry!), since there are two containers extensions, yours and firefox's. one.

So, here are two logs:

Blank Page:
firefox_TC_logs_blank_page.txt

Firefox home (empty):
firefox_TC_logs_firefox_home_empty.txt

[stoically]

Well, even with "Firefox Home" onCreated fires about:blank in your case, which causes the slightly longer delay. While testing I had that behavior with an old profile of mine too, creating a new one fixed it. So you could try about:profiles, create a new profile, launch it and see how TC behaves with the default "Firefox Home". If that doesn't helper either, there's only the Don't reopen option left (which you essentially already used with "Blank Page" before TC version 0.92), since the Firefox API doesn't provide the needed information to improve the behavior in this case.

[grenzor]

FWIW, I remember a year back new tab with about:blank set (before it stopped working around #146) it used to open a new tab in container instantly without any delay at all. Now testing in a new profile with either about:blank or about:home with all checkboxes unticked I do notice the slight delay is there with both. Don't know if something inadvertently changed on TC's end or if Firefox changed something around version 61 when https://github.com/stoically/temporary-containers/issues/146#issuecomment-456556264 was that issue was said to be fixed.

[stoically]

Did some digging, and it seems that starting with version 60, Firefox started to respect the browser.newtabpage.enabled config, so if for whatever reason you had that configured, you suddenly ended up with a blank page and no way to change that in the UI. With version 61 the "New tabs" preferences was introduced in the UI.

TC never worked with "Blank page" tabs, until version 0.92, that's why you could end up with #146 after the upgrade to Firefox 60. The fix introduced for that to work has the downside, that it has to wait for the tabs.onUpdated event to fire before it can reopen in a TC, which is slower than listening to tabs.onCreated - which in this case isn't possible because actual "new tabs" and tabs opened from a website that immediately start loading a website, look exactly the same from the API perspective (url: about:blank, status: complete).

With "Firefox Home" configured, it depends on the mood of your Firefox (nothing changed in TC related to that since like ever). Sometimes onCreated fires with about:blank (waiting delay until onUpdated), and sometimes with about:newtab (instant reopening possible). Unfortunately it's expected behavior (Bug 1411554, Bug 1541847) that this behaves differently for users. In my testing I've experienced both scenarios even with the same Firefox version.

[grenzor]

It's weird since I have always set about:blank and TC opened new tabs in new containers instantly every time in Firefox <60 but definitely looks like there is some kind of behavior in Firefox that determines why this happens. Regardless it seems there isn't much that can be done here, thanks for trying your best @stoically :)

[kyounger]

Is it fair to say that this is most easily fixed by remapping keystrokes external to firefox so that Cmd-T => Alt-C? :)

[stoically]

That'd be indeed a good workaround, though I'm not sure how easy that actually is, depending on your platform. If you figure it out on your platform, leaving a how to comment would be appreciated.