Thanks for bringing in some background info about why we created the FxOS specific neterror page in the first place!
Your proposal appears sound to me :-) On 13.11.2015 10:10, Michael Henretty wrote: > 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] > <mailto:[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] > <mailto:[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]> > > <mailto:[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]> > > <mailto:[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]>> > > >> <mailto:[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]>> > > >> <mailto:[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]>> > > <mailto:[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]> > <mailto:[email protected] > <mailto:[email protected]>> > > >> https://lists.mozilla.org/listinfo/dev-fxos > > >> > > > > > > > > > > _______________________________________________ > > dev-fxos mailing list > > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > https://lists.mozilla.org/listinfo/dev-fxos > > > > > > > > _______________________________________________ > > dev-fxos mailing list > > [email protected] > <mailto:[email protected]> > <mailto:[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
