+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
