search

kite-project / hope

A new web experience for your B2G and Android devices.
8 stars 3 forks source link

Make the URL bar work #14

Closed wilsonpage closed 8 years ago

wilsonpage commented 8 years ago

Open questions:

  1. Do we need to use mozbrowser to get (normally) hidden data/events from the child iframe?
  2. Do we need to address search as part of this issue? I vote follow up.
  3. Should we be using something like <little-browser> to give us swiping back/forward UX and faux prerending?
wilsonpage commented 8 years ago

@etiennesegonzac

jonathanKingston commented 8 years ago
  1. separate issue makes a lot if sense.

Another follow up: Can there also be a context aware predictive keyboard also for domain extensions? (This will mostly have to be based upon the users input language as coping with right to left and left to right extension prediction is hell on wheels). ICAAN publish all the extensions etc (Not sure if an exhaustive list is in b2g) and the code to predict would mostly be simple however I'm not sure how the gaia keyboard works etc.

etiennesegonzac commented 8 years ago

Ooh yeah we should do the minimum for the first issue. Maybe even keeping some of the fake content initially.

We want to make the iframe mozbrowser for the back forward chrome (canGoBack and all) and remote so that they get their own process.

We can explore with the little browser later on :)

On Mon, Jan 4, 2016, 3:04 PM Jonathan Kingston notifications@github.com wrote:

  1. separate issue makes a lot if sense.

Another follow up: Can there also be a context aware predictive keyboard also for domain extensions? (This will mostly have to be based upon the users input language as coping with right to left and left to right extension prediction is hell on wheels). ICAAN publish all the extensions etc (Not sure if an exhaustive list is in b2g) and the code to predict would mostly be simple however I'm not sure how the gaia keyboard works etc.

— Reply to this email directly or view it on GitHub https://github.com/etiennesegonzac/hope/issues/14#issuecomment-168787866 .

wilsonpage commented 8 years ago

@etiennesegonzac the hope iframe doesn't seem to have the mozbrowser permission at the moment. I'm not sure why this is.

wilsonpage commented 8 years ago

@etiennesegonzac r?

wilsonpage commented 8 years ago

I tried getting rid of the iframe inside sytem, but I found it lead to a whole bunch of new problems breaking all the URLs etc. Eventually found a way to create an iframe and inject the content from the system app so that it inherited the permissions. Hacky, but I don't see another way right now. At least we haven't broken the standalone app.

jonathanKingston commented 8 years ago

I've loaded facebook.com and bbc news as real apps by default. We can see performance does suffer when real sites are in the DOM. I guess this is down to DOM size.

Do inactive tabs need to be the full DOM? Does detaching the DOM for later usage help then reattaching when selected? If so a canvas might help perhaps.

Reader mode and refresh icons are incorrect color on top of themed URL bar. When these become font/svg, we can dynamically color them. But perhaps we'd like to revert to grey url bar for all apps.

I'm not sure on the implementation stage in gaia of the secure contexts spec (I really should sorry -I'll keep using the on holiday excuse and hope it sticks :smile_cat:). However perhaps the theme colour should only be applied when in a secure context (I'm not sure on the plan on indicating to the user when they are looking at secure content) this appears to be how Google applies theme colour anyway. Anyway when this API is available it should be useful in deciphering when the page is secure or not: https://w3c.github.io/webappsec-secure-contexts/#dom-window-issecurecontext

Update: https://bugzilla.mozilla.org/show_bug.cgi?id=1162772 seems it is not implemented yet.

Update2: https://developer.mozilla.org/en-US/docs/Web/Events/mozbrowsersecuritychange seems to cover the same usages