Michael, Probably the way to get the best of the both worlds is:
1. Allow user to access Gecko about: pages from System Browsers (which loads with chrome permissions), avoid re-implementing every page in Gaia. 2. Allow customization from System app to overwrite specific about: pages like netError (and have these pages loads in System app permissions). I don't like the fact System/Settings becoming some kind of a special app where we dump things no-where-to-put into it, but I agree your use case on netError is valid. I just don't like the fact we are creating extra work by putting permission barrier and then break it with hacks. The alternative is probably grant chrome permissions to System & Settings*, but that won't do us any good either. So I ask instances of (2), including index.html of System app (which is essentially our browser.xul), to be properly engineered with WebIDL-enforced APIs. * Settings app is just like our "about:preferences" in some way. Have (1) and (2) co-exists is a state I can live with, again, if (2) are properly worked on. On Sat, Nov 14, 2015 at 12:11 AM, Frederik Braun <[email protected]> wrote: > 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
