Closed Bug 1283891 Opened 9 years ago Closed 9 years ago

Bootstrap e10s-compatible add-on requires restart for Windows 10 for FF 48b5

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Version:
48 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: steven.harris, Unassigned)

References

(
URL
)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Steps to reproduce: The same steps were performed on a Win7 and Win10 system. Only Win10 demonstrated this issue. 1. Usin FF 48b5, navigate to http://download.fromdoctopdf.com/index.jhtml?partner=%5EY6%5Eyyyyyy%5ETTAB02 2. Check the check box, then the Download button 3. Respond to the installation dialogs Actual results: The user sees the "Product will be installed after you restart Firefox" dialog Expected results: The user should see the Product installed w/out requiring a restart. The Add-on is installed as expected in Win7, w/out requiring a restart. Further, the install.rdf correctly states that it is a bootstrap XPI.
I suspect what's happening here is that your Win7 system is running Firefox with e10s disabled, and Win10 is running Firefox with e10s enabled. Installing the addon can result in e10s getting disabled, because e10s does not yet support many types of addons. Can you go to about:support on both systems and copy what it says under the "Multiprocess windows" line into this bug? Thanks!
Flags: needinfo?(steven.harris)
I tried this issue on Windows 7 with FF 48.0b5, Build ID 20160630123429, User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0 and I can confirm the followings: - with e10s disabled the add-on is installed successfully without requesting restart. In about:support at "Multiprocess Windows" line I have: "0/1 (Disabled)" - with e10s enabled restart is requested. For e10s enabled, I had set browser.tabs.remote.autostart=true, and in about:support, at "Multiprocess Windows" line I have: "1/1 (Enabled by user)"
With e10s enabled, after the browser restarts, does about:support indicate that e10s is disabled by addons?
After restarting the browser, in about:support for Multiprocess Windows is "0/1 (Disabled by add-ons)"
Thanks, that's basically what I expected then. I think this bug is really expected behaviour, assuming Steven is seeing the same thing as you. Leaving needinfo for the time being.
In about:support, Multiprocess Windows - Win10: 0/1 (Disabled by add-ons) - Win7: 0/2 (Disabled) This supports your understanding and changes this from a bug to expected behavior. Thank you for your prompt attention on this matter.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(steven.harris)
Resolution: --- → INVALID
IMPORTANT: I thought all platforms were going to behave the same regarding e10s. Therefore, the fact that Win7 and Win10 differ on this feature is a surprise. Please confirm that the intent is to have e10s enabled by default for Win10 while other versions of Windows will have it disabled, as this will have a negative impact on our business.
(In reply to Steven Harris from comment #7) > IMPORTANT: I thought all platforms were going to behave the same regarding > e10s. Therefore, the fact that Win7 and Win10 differ on this feature is a > surprise. Please confirm that the intent is to have e10s enabled by default > for Win10 while other versions of Windows will have it disabled, as this > will have a negative impact on our business. It's not specific to Win7/Win10. On 48 beta, 50% of the eligible population is randomly selected to get e10s enabled. It just so happened that one of your systems got it enabled and the other got it disabled. The reason for the 50% split is so that we have continued testing of both e10s and non-e10s codepaths all the way through to the end of the beta cycle. Note also that be "eligible population" I mean users with whitelisted addons only (as you discovered, some add-ons will disable e10s because they're not compatible) and who also do not have accessibility tools activated (again, e10s is not compatible with accessibility tools yet, but we're in the process of fixing that). Windows devices with touchscreens automatically activate accessibility, so those will generally have e10s disabled as well.
Kartikaya, thank you for your quick response :) What mechanism is used to determine if an Add-on is compatible? Our extension has a lot of legacy code that may not be compatible, but our current usage does not reference any of that code. Of note, we could not use the compatibility tool because our product is not distributed via the store.
Kartikaya, can I presume that the compatibility check is done by examining the <em:multiprocessCompatible> in the install.rdf?
(In reply to Steven Harris from comment #10) > Kartikaya, can I presume that the compatibility check is done by examining > the <em:multiprocessCompatible> in the install.rdf? Correct! https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#multiprocessCompatible
Update: We've added the <em:multiprocessCompatible> true flag to the RDF, resigned via AMO and are still seeing the restart scenario. What is the next step I should take to make progress on this?
Can you check what about:support says for the "Multiprocess Windows" line before and after installing the add-on?
Hi, the multiprocess Windows value changes in exactly the same way as before. 1. pre installation of add-on, value is 1/1 (Enabled by default) 2. post installation and browser bounce, value is 0/1 (Disabled by add-ons)
Jim, do you know who owns the e10s-compatibility checker code for addons? ^
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(jmathies)
Resolution: INVALID → ---
Summary: Bootstrap add-on requires restart for Windows 10 for FF 48b5 → Bootstrap e10s-compatible add-on requires restart for Windows 10 for FF 48b5
I think felipe worked on that, but I do think we're working as advertised. From my understanding, if a user has e10s enabled to start, and installs an add-on - any add-on, compatible or not - we force Firefox to restart and for e10s to be disabled, with the goal being that only users without add-ons are running with e10s on the release channel. I believe the whitelisting of some set of compatible add-ons is on the horizon, but the timeline is unclear to me. ni'ing shell who knows this stuff really well.
Flags: needinfo?(sescalante)
added Kev to respond to more question, as i'm on PTO end of this week. goal is to have the "allow list" in beta 49 and 50 and then to release in 50. with potentially getting the 3 add-ons from discovery pane in for 49 release as they are featured in a new "discovery pane") to release (Kev will be working that process. bug 1247497
Blocks: 1247497
Flags: needinfo?(sescalante) → needinfo?(kev)
Yeah, this is working as intended. On Firefox 48, all add-ons, even those marked with <em:multiprocessCompatible>, will disable e10s (on the beta and release channels). The plan is to start allowing them to run together with 49 or 50 (that is yet to be decided depending on how our experiments on beta go).
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Flags: needinfo?(kev)
Flags: needinfo?(jmathies)
Resolution: --- → INVALID
This is unexpected behavior as we are a restartless extension and this essentially ignores that fact and forces a restart. Will there be broad rollout of this behavior in Firefox 48 GA? If so there will be significant impact for us. What would be our options to mitigate?
This is not resolved to our satisfaction so reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
This is the behavior that will roll out, but note that this only happens when e10s is active. Meaning that it only happens when going from 0 add-ons installed to 1 add-on installed (in which point e10s gets disabled). Any user who already have add-ons, or are ineligible for e10s for other reasons, won't be affected. Also, the 48 e10s rollout will be smooth and won't happen instantly.
Please accept our thanks for your contributions to this ticket, and the timeliness of your responses. Another question - what role does the multiprocessCompatible flag play in this rollout? From everything that's been stated to date, my understanding is that this flag will be ignored for the A/B testing happening with beta right now, as the goal is to answer how well e10s performs in the wild on systems with NO add-ons. But, my guess is that this flag will be respected once 48 goes GA, so the restart issue we are talking about will only apply to add-ons not self identifying as multiprocessCompatible.
On beta 48, you're correct that we tested how well e10s performs in the wild with no add-ons. So this is how we're going to GA (e10s only for no add-ons), since this is the configuration that we're confident that e10s works well. Starting on beta 49 we'll be testing e10s with add-ons with the goal of rolling it out gradually during 49 and 50 GA. The multiprocessCompatible flag will be useful because those add-ons will get priority in when we start testing them with e10s. The timeline is still being defined, but this is my current understanding of it: First phase: - add-ons written with the new WebExtensions API - whitelist of known-to-be-good most popular add-ons Second phase: - add-ons marked multiprocessCompatible Later phases: - more add-ons, to be determined Maybe phases 1 and 2 will happen in 49, maybe just 1, it all depends on how good or bad the data from phase 1 turns out to be
Thank you. Where can we learn more about the add-on 'whitelist' mentioned above?
Please get in touch with Kev (mentioned in this bug) as I'm not involved with the list creation. I don't think there's anything posted on a wiki yet but I'll make sure something gets posted in the upcoming days. Are you fine with closing this bug now? Hopefully all concerns have been clarified.
I will close this ticket and connect with Kev to learn more about the 'whitelist' process. Thank you.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → INVALID
Filipe, it seems I closed this ticket prematurely. In looking at your response to my question yesterday (thank you) I am still not clear as to how the multiprocessCompatible flag will be used by FF 49 and 50. Your response seems to focus on how the flag will be used to help your team test add-ons, not on how the browser will react to the presence/absence of the flag. Can you please clarify?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
So, what we'll be testing is what we plan to ship. At some point when 49 or 50 is in beta, we'll test enabling e10s for users with add-ons marked as multiprocessCompatible. If the data from that experiment us confidence that everything looks good (no spike in crashes/bug reports/performance problems), then we'll let that roll out to GA.
Responded to Steven and his team out of band on process behind e10s testing and what we're doing with the whitelist. Steven, is there more information that's required at this point? Per Felipe's comments and mine, restartless add-ons will be affected in Fx48, and we're asking developers to ensure their addons are flagged as multi-process compatible. Please let me know if additional info is required at this point. (In reply to Steven Harris from comment #26) > I will close this ticket and connect with Kev to learn more about the > 'whitelist' process. > > Thank you.
...and we'll also be posting next week on the AMO blog and adding info to MDN to outline effects on restartless with e10s enabled versions of Firefox to make it clearer.
I think one more question we still have is regarding new installs of addons. When FF49 or 50 starts to roll out e10s testing for those whitelisted addons, will it only roll out to users that already have them installed? Will new installs of those addons continue to trigger a disablement of e10s, and therefore cause a restart of the browser?
Another question, is there any plan for a way to programmatically determine e10s status from a web page? Perhaps something in the user agent string? Thank you all for providing this info, and I hope you can understand our concern about this subject. This return to "restartful" add-on behavior has the possibility of causing a large negative impact the business of add-on developers for new installs.
Hi team, Max Peterson was speaking on my behalf so I would appreciate it if you could answer his questions.
Flags: needinfo?(kev)
Flags: needinfo?(felipc)
Hi there, replies below. (In reply to Max Peterson from comment #31) > I think one more question we still have is regarding new installs of addons. > When FF49 or 50 starts to roll out e10s testing for those whitelisted > addons, will it only roll out to users that already have them installed? > Will new installs of those addons continue to trigger a disablement of e10s, > and therefore cause a restart of the browser? No. When we start testing that, both current installs or new installs of those add-ons will allow e10s to run, and therefore won't require a restart to disable e10s. As for detecting e10s from a webpage, no we don't want to expose that information to the web. For users, e10s is just an under-the-hood change that should be transparent.
Flags: needinfo?(kev)
Flags: needinfo?(felipc)
Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit
This bug has outlived its usefulness, please open a new bug if anything new arises.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.