InformAction Forums

Hello!
NS2.9.03, Nightly 03-02-16, e10s enabled (e10s disabled=bug is not reproduced). STR:
Create new profile, launch Nightly, right click on the tab bar - Customize - Click once on "Title Bar"
Close Customize, press Alt, go to Tools - Addons, install NoScript, restart, Default browser - not now, open new tab and go to http://forums.mozillazine.org/viewforum.php?f=23, ctrl-click on "Multiprocess Firefox [e10s] (ETA Fx46/47/48)", open new tab using new tab button then click on two mozillazine tabs you've just opened - tab title not updated!

Is this with e10s enabled or disabled?

barbaz wrote:Is this with e10s enabled or disabled?

e10s enabled. If e10s is disabled, bug is not reproduced. Updated the first post.

NoScript 2.x is not expected to fully work with e10s, need to wait for NoScript 3.x
https://bugzilla.mozilla.org/show_bug.cgi?id=1058542

barbaz wrote:NoScript 2.x is not expected to fully work with e10s, need to wait for NoScript 3.x
https://bugzilla.mozilla.org/show_bug.cgi?id=1058542

I heard Maone is planning to rewrite NoScript as WebExtension so we won't see e10s-compatible NoScript that uses current APIs. Is that info correct? I am asking because I use NoScript 24/7 and I am afraid NoScript won't be compatible with e10s when it is enabled in the release channel.

Thanks.

GH113 wrote:

barbaz wrote:NoScript 2.x is not expected to fully work with e10s, need to wait for NoScript 3.x
https://bugzilla.mozilla.org/show_bug.cgi?id=1058542

I heard Maone is planning to rewrite NoScript as WebExtension so we won't see e10s-compatible NoScript that uses current APIs. Is that info correct?

Partially.
I'm gonna fix bugs which make current XUL-based NoScript incompatible with e10s, but won't optimize it for e10 neither spend much time on new features until the WebExtensions version is ready.
This seems an instance of the former case, so I'm investigating, thanks.

On windows 7 with NoScript installed the title in the taskbar is not always updated. Disabling NoScript fixes the problem. I have seen the problem on two independent machines.
- To display titles: right click task bar, choose "properties", set "Taskbar buttons" to "Never combine".
- If you have just opened the browser wait about 8 seconds with no navigation.
1. If you open new tab, the taskbar title changes to match the new tab. (correct behavior)
2. If you navigate to a new location in the new tab (e.g. enter a url or click a link), the taskbar title is updated. (correct behavior)
3. If you close the new tab (e.g. Ctrl+w or click the "X" on the tab), the taskbar title is not updated. (wrong behavior)
4. If you switch to another tab (e.g. Ctrl+tab or by clicking it), the taskbar title is not updated. (wrong behavior)

Does the same happen on a clean profile with only NoScript installed?

Does this happen only on Firefox 47?

Yes, it happens in a clean profile with only NoScript installed.

Sorry, I forgot to mention the browser version explicitly, but I guess you checked the logs. I have only tried this in DevEdition, i.e. 47 and 46 and few weeks ago. Are you curious about newer or older versions?

I'm curious if it happens in beta or release.

I ran "mozregression -g 2015-01-01 --addon noscript-2.9.0.10.xpi" and got this (the last downloaded nightly where called 47.0a1, so release is probably not affected):

Narrowed inbound regression window ... to [c0ba5835, c8f9b2cd] (2 revisions) (~1 steps left)
Last good revision: c0ba5835ca489d15f8f170d5deb01f8dad92709a
First bad revision: c8f9b2cd16885eb5db980b907fdfbd6807f19f2a
Pushlog:
https://hg.mozilla.org/mozilla-central/ ... 6807f19f2a

Thanks for the detailed information!
Now all there is to be done here is wait for Giorgio to look at it when he has time.

I've already created a thread about this problem before with STR:
viewtopic.php?f=10&t=21592
This is e10s-only bug so I guess Giorgio won't fix it.

Thanks for pointing that out; merged.

This problem seems to affect more UI elements than just the title.

Screenshot taken under Win7 32 bit, Firefox 49.0a2, NoScript 2.9.0.12rc1:


I had to switch several times between the two tabs to get this result. With multi-process support (e10s) disabled I wasn't able to reproduce this behavior.