The reason we moved netError into the system app was for UX reasons more than anything else [1]. We wanted to have UI allowing users to easily configure their network connection when getting a network error. The initial implementation had the system app detect the network-error, and then display an overlay that would allow changing these settings. But this was pretty strange and poor UX. So we moved the netError.xhtml page from Gecko to the System app so we could do things like leverage building blocks, and use the System app's permission level inside the mozbrowser iframe (IIRC the old netError.xhtml in gecko inherits the permission level from the current content frame and so can't change settings).
In any case, I'm not sure what we would gain by moving netError.xhtml back into Gecko. It was already b2g specific since it lived in `b2g/chrome/content/netError.xhtml`. And in any case, it's nice to have b2g specific functionality like using mozActivities and configuring settings. If we are going to have more `about:xxx` pages in Firefox OS, I think it's fine to use Fennec stuff since it requires less work. But moving netError back into Gecko for the sake of product unification with Desktop and Fennec seems like a step back in UX to me. 1.) https://bugzilla.mozilla.org/show_bug.cgi?id=882186#c24 On Thu, Nov 12, 2015 at 1:27 PM, Kartikaya Gupta <[email protected]> wrote: > Maybe you can reuse the ones that Fennec has? They have rewritten some to > be more mobile-friendly and are using the desktop versions for others, > AFAIK. > > kats > On Nov 12, 2015 3:24 AM, "Frederik Braun" <[email protected]> wrote: > >> +1, >> >> I too think that we should allow accessing the Gecko about: pages built >> into platform. They are usually not meant for the "average user", so I'd >> suggest we can live with some being not "mobile optimized", while doing >> this in a later iteration upstream. >> >> On 12.11.2015 06:06, Tim Guan-tin Chien wrote: >> > (I was going to respond to another thread but this seems to be fit in >> more) >> > >> > I don't think Firefox OS (specifically Gaia) should re-implement every >> > about: page in Gecko. There is just too much work for the Firefox OS >> > team to reproduce every about: page that is already done by the Platform >> > team. >> > >> > Sure, we want to get them (1) localized in Gaia or maybe (2) >> > customizable with new UI in Gaia System app, but I think (1) can be done >> > by having the Gecko about: pages localizable by Gaia System language >> > packages and (2) should not be a priority if we are all working at the >> > same company and try to produce multiple products with consistency. >> > >> > Unless there are arguments on (1) is not doable or (2) is indeed a >> > shared goal across the entire company (thus invalid bug 1217269 at least >> > partly), we should try to achieve (1), make about: accessible in FxOS, >> > and move neterror.xhtml back to Gecko. >> > >> > The work involved to re-create about: UIs in Gaia System / Gaia >> > Settings, as evidenced by the previous thread, involves non-trivial API >> > engineering and/or IAC hacking. I don't think it's a desired direction >> > in terms of architecture or use of our human resource even though >> > Fernando can keep the test coverage we are happy with. >> > >> > This needs a resolution. The conversation should have happened 3 years >> ago. >> > >> > >> > On Thu, Nov 12, 2015 at 12:04 AM, Naoki Hirata <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > https://bugzilla.mozilla.org/show_bug.cgi?id=886905 >> > >> > You are more than welcome to fix the pages so they work for Firefox >> > OS. :) >> > >> > On Tue, Nov 10, 2015 at 11:41 PM, Frederik Braun < >> [email protected] >> > <mailto:[email protected]>> wrote: >> > >> > There are many other useful about pages that do not currently >> > work on >> > Firefox OS (config, memory, crashes, webrtc, mozilla, robots, >> > ... :)). >> > >> > Do we want them to work in the future? Either by just allowing >> > them from >> > the browser app or redirecting to a customized version from the >> > system app. >> > >> > >> > On 11.11.2015 07:05, Fabrice Desré wrote: >> > > The only about: page we display is about:neterror. On b2g we >> > redirect it >> > > to a page served from the system app >> > (apps/system/net_error.html). The >> > > nice thing doing that is that we have control of its look & >> > feel (even >> > > if we started by mostly copying the one from Fennec), and we >> can >> > > localize it like the rest of gaia. That means th >> > at we don't have to ship >> > > a localized gecko, which is a win. We still have some >> unlocalized >> > > strings in gecko that we should provide from the system app >> > though, like >> > > the label on <input type=file> buttons. >> > > >> > > Fabrice >> > > >> > > On 11/10/2015 07:50 PM, Tim Guan-tin Chien wrote: >> > >> Understood, thanks for the response Francisco, Fernando and >> Ben! >> > >> >> > >> Maybe the bigger issue here is whether or not we should >> > somehow allow >> > >> about: URLs to be loaded into FxOS? I don't think it make >> > sense for >> > >> re-do every about: page UI in the FxOS org since Platform >> > team already >> > >> did it once? >> > >> >> > >> >> > >> On Wed, Nov 11, 2015 at 1:46 AM, Francisco Jordano >> > <[email protected] <mailto:[email protected]> >> > >> <mailto:[email protected] <mailto:[email protected]>>> >> > wrote: >> > >> >> > >> Hi there, >> > >> >> > >> as Ben mentioned there is a new effort from the devtools >> > team to >> > >> provide tools for debugging the new features that >> > platform is building. >> > >> >> > >> IIRC, Eddy is working on the new tools under >> > about:debugging that >> > >> will be the umbrella for debugging addons, workers, >> > serviceworkers, etc. >> > >> >> > >> We still don't have it available for FxOS, so IMO, we >> > should keep >> > >> the current implementation in Settings that provide basic >> > >> functionality for developers, and remove that >> > implementation as soon >> > >> about:debugging is available for Firefox OS. >> > >> >> > >> Cheers, >> > >> F. >> > >> >> > >> On 10 November 2015 at 14:04, Ben Kelly >> > <[email protected] <mailto:[email protected]> >> > >> <mailto:[email protected] <mailto:[email protected]>>> >> > wrote: >> > >> >> > >> On Tue, Nov 10, 2015 at 2:32 AM, Tim Guan-tin Chien >> > >> <[email protected] <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>> >> wrote: >> > >> >> > >> Somehow it was decided about:serviceworker in >> > Settings app >> > >> should be engineered with a chrome/content event >> > to System >> > >> app and an IAC channel to Settings app: >> > >> >> > >> >> > >> https://github.com/mozilla-b2g/gaia/blob/3180bbe2f2e94809c1fcef0e92a01da99cdfb530/apps/system/js/about_service_workers_proxy.js#L21-L29 >> > >> >> > >> When, per previous threads, we should just >> > implement a >> > >> ServiceWorkerManager API accessible from Settings >> > app. >> > >> >> > >> >> > >> Is it really necessary to have this panel in settings >> > app vs >> > >> providing the information via devtools? >> > >> >> > >> The main issue with the previous settings app service >> > worker >> > >> panel is that it could run the service worker script >> > in the >> > >> wrong content process. For example, when you click >> > the update >> > >> button it would launch the service worker script for >> > appId X in >> > >> the settings content process with appId Y. This >> > would then >> > >> cause security checks to fail and kill the content >> > process. >> > >> >> > >> If necessary we can surface a small interface to >> > settings app, >> > >> but I would strongly suggest that it be limited in >> > scope. We >> > >> should not expose the full nsIServiceWorkerManager >> > interface. >> > >> It would also need to include IPC to the parent >> > process to work >> > >> properly. >> > >> >> > >> >> > >> Unless there are counter-arguments unknown to me, >> > I would >> > >> like to organize work and do this conversion. >> > >> >> > >> >> > >> We are planning to revisit our service worker e10s >> > design for >> > >> b2g at the December work week. I would recommend >> > waiting to do >> > >> any major changes until after that session. >> > >> >> > >> Ben >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> dev-fxos mailing list >> > >> [email protected] <mailto: >> [email protected]> >> > >> https://lists.mozilla.org/listinfo/dev-fxos >> > >> >> > > >> > > >> > >> > _______________________________________________ >> > dev-fxos mailing list >> > [email protected] <mailto:[email protected]> >> > https://lists.mozilla.org/listinfo/dev-fxos >> > >> > >> > >> > _______________________________________________ >> > dev-fxos mailing list >> > [email protected] <mailto:[email protected]> >> > https://lists.mozilla.org/listinfo/dev-fxos >> > >> > >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos >> > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
