Address isn't understood when e10s is enabled

[Scrxtchy]

Using Latest Waterfox, pressing the extension button brings me to this page

[Scrxtchy]

Mitigated locally by navigating to chrome://ca-archive/content/ca-archive.html

[JustOff]

You probably forced e10s on, unfortunately CAA can't run in this mode for now.

[JustOff]

I'll try to get it work with e10s, but at the moment it's obviously not my top priority.

[mparnelldmp]

In Waterfox, I have this option, I think because of Tab Mix Plus.

[JustOff]

It seems this is Waterfox-specific feature, patches to run CAA in non-e10 window are welcome.

[grahamperrin]

As a side note, e10s is enabled by default in Waterfox 56 and not automatically disabled when incompatible extensions are enabled.

[grahamperrin]

… patches to run CAA in non-e10 window are welcome.

I'd love to contribute but (sorry) no relevant coding skills.

@MrAlex94 please: for the next release of Waterfox (56.2.4, I guess) do we need to seek additional help with this issue?

[grahamperrin]

(Convoluted workaround for Waterfox non-e10s windows moved to BrowserWorks/Waterfox#755 (comment).)

[JustOff]

That is not a good workaround; please don't share it.
Check CAA 1.2.1b1, which tries to run in a non-e10s window.

[grahamperrin]

Thanks!

1.2.1b1 is much better. Hopefully no longer any situation in which the modal dialogue will appear.

A couple of edge cases

1

A special URL e.g. about:… as the first and only tab in the only window when Waterfox starts.

2

A preference to Show your windows and tabs from last time when Waterfox starts, with an extension such as Speed Dial caa:addon/speed-dial affecting new tab behaviour, and with the affected tab frontmost in a sole window before quit:

---

In cases such as these there'll be the generic information page:

The address wasn't understood

– with a tab context menu workaround:

Alternatively:

1. close the caa: tab
2. bring to front any tab with a normal (e.g. http:// or https://) address
3. reuse the Classic Add-ons Archive button.

[JustOff]

The problem here is that Waterfox does not restore the non-e10s status of the windows after restart, so they become unsuitable for caa: scheme. This is pretty sad and now I don’t even know if it's worth using non-e10s windows at all or is't better to return the requirement to disable multi-process mode so as not to confuse anyone with the issue after restarting.

See also CAA 1.2.1b2 = CAA 1.2.1b1 + warning.

[grahamperrin]

1.2.1b2 feels regressive compared to 1.2.1b1.

I could not remember the two-step workaround that I edited out of the foot of (opening post) BrowserWorks/Waterfox#755 (comment).

After I called up an archived copy of that post, 1.2.1b2 felt no different from 1.2.0. (Is there a difference between those two versions?)

… if it's worth using non-e10s windows …

I do think so. 1.2.1b1 felt smart and is likely to satisfy a majority of users.

(The two cases I gave above #2 (comment) are probably very edgy.)

[JustOff]

Please try CAA 1.2.1b3.

[grahamperrin]

I seem to get mixed results with 1.2.1b3.

The first impression was good; it was easy to get a window with caa: working.

Later use of the same profile was not easy. I could get only the modal dialogue, with its insistence upon disabling multi-process.

(Maybe the first impression was based on me aiming immediately for the workaround, in response to the generic … not understood … text. Honestly I can't recall exactly what I did immediately at the start of the test.)

Does 1.2.1b3 lack the (1.2.1b1) ability to automatically open a new non-e10s window?

Wording for the non-modal red alert at caa:

Instead of:

Waterfox in multi-process mode can't restore caa: urls after restart!

– maybe this:

Multi-process Waterfox does not save non-e10s state when saving sessions

[JustOff]

I could get only the modal dialogue, with its insistence upon disabling multi-process.

This modal dialog is called from the block if (mode == e10s && appname != "Waterfox"); do you use any extensions or other ways to hide or fake the application name?

Here is how to check your appname:

1. Open Scratchpad (Shift+F4)
2. Set Environment to Browser
3. Paste alert(Services.appinfo.name); and click Run

Does 1.2.1b3 lack the (1.2.1b1) ability to automatically open a new non-e10s window?

All 1.2.1bX versions have this ability, they differ in the manner in which the e10s mode is detected and in the presence of a non-modal warning.

Wording for the non-modal red alert at caa:

Sorry, but your wording is too general to be useful for the average user.

[grahamperrin]

… do you use any extensions or other ways to hide or fake the application name?

I'm testing in a profile that has just the one extension.

[JustOff]

Then I absolutely don't understand how you can see "Multi-process mode is not supported" in 1.2.1b1-b3 🐼

[JustOff]

@grahamperrin, if you can still reproduce the issue with "Multi-process mode is not supported" is displayed, please email me a copy of the test profile where it's observed (you can reduce the size of the profile by excluding the ca-archive, startupCache and cache2 folders from it).

[grahamperrin]

Here it was, the modal, with 1.2.1b3 a few minutes ago (two frames from a screen recording, three seconds apart):

After removing the extension, quitting, starting, adding the same version: behaviour was quite different – much better, of course :-)

Mysterious.

Unfortunately (sorry) I didn't set aside a copy of the affected profile before working around the mystery but as seen in the second shot above, it was very clean.

---

PS if it helps to de-mystify: I have a very clear recollection of one of the betas (maybe the first) of 1.2.1 appearing as 1.2.0 at about:addons … I didn't take a shot at the time, I just assumed that you had given a distinctive file name to the .xpi whilst leaving it as 1.2.0 internally. Can't recall which profile was in use when I saw the discrepancy, sorry. I tried, failed, to reproduce the discrepancy.

[JustOff]

This drives me crazy, 2+2=5 😧

Here is CAA 1.2.1b4, which displays appname instead of "the browser" in the modal dialogue:

if (e10s && Services.appinfo.name != "Waterfox") {
  Services.prompt.alert(null, "Classic Add-ons Archive", 
  "Multi-process mode is not supported now,\nplease disable it and restart " + 
  Services.appinfo.name + ".");
  return;
}

[grahamperrin]

Well … (if we treat the first screenshot in my previous comment as inexplicable) I can not find any situation in which the modal dialogue appears.

Am I missing something?

---

PS I'm testing primarily with 56.2.3 on FreeBSD-CURRENT, which I expect to be no different from the official 56.2.3 for Linux, for CAA purposes. That's my expectation but for sanity, I'll bring a Kubuntu machine into the mix.

[JustOff]

This dialogue should never appear in Waterfox, I just don't like to leave inexplicable things unexplained.

[grahamperrin]

This dialogue should never appear in Waterfox, …

OK 👍

[JustOff]

I'm going to release 1.2.1 tonight to verify the e10s workaround in the wild.

[grahamperrin]

Yep, it feels release-ready to me. Wild time. Thanks.

---

Back to the opening post, the generic message:

The address wasn’t understood

For #2 (comment) above and the plain English red alert –

Waterfox in multi-process mode can't restore caa: urls after restart!

– I raised the issue in the Waterfox repo:

• Multi-process Waterfox does not save non-e10s state when saving sessions · Issue #761 …

[BGMcoder]

Yes, I have the same problem. CAA gives a "The address wasn’t understood" message in Waterfox 56.2.8 (64-bit). TMP installed and e10's is enabled. It works if I disable e10s. Just confirming.