2009/9/22 Erik Kay <[email protected]>

> On Mon, Sep 21, 2009 at 5:54 PM, Jeff Timanus <[email protected]>
> wrote:
> > Thanks for your comments, Erik.
> > Responses inline below.
> >
> > 2009/9/21 Erik Kay <[email protected]>
> >>
> >> Hi Jeff,
> >>
> >> Sorry for the delay on feedback to your proposal.  This got lost in the
> >> shuffle.
> >>
> >> - I'm nervous about the absolute positioning use case.  I'd be tempted
> >> to remove this (or perhaps move it into a separate proposal).  What
> >> are some use cases you were envisioning here?
> >
> >
> > The main use case I envisioned was for implementing right-click handlers.
> >  If the pop-up had to be anchored to a DOM object, on right-click we
> would
> > have to dynamically create a new div and then anchor off of that.
>  Because
> > right-click handlers felt like a common usage-model for pop-up API's, I
> felt
> > that the inclusion of this mode worth-while.
>
> I see.  So for absolute positioning, it would be bounded by the frame
> of the originating view, right?  I was concerned that you wanted to
> use this for generic browser overlays.  Constrained makes me less
> nervous.
>

The pop-up is constrained in that the anchor point, as described in the doc,
must be located within the launching extension view.  Otherwise the window
may be extended arbitrarly.

>
> On the flip side, our tendency with API design has been to try to be
> more specific to the actual use case.  If the goal of this is to
> support right-click menus, then I guess I'd be tempted to step back
> and think about that as a specific (but separate) API proposal.
>

Wouldn't the right-click handler be exactly the same functionality, save for
perhaps the lack of a few options?


>
>
> >> - Why make left-right an argument?  The browser should know whether
> >> it's running in left-to-right or right-to-left.  Do you envision a
> >> place where the extension has one behavior and the browser another?
> >
> > Hmm.  You make a good argument.  I had callers of the absolute-mode
> > positioning would want fine-grained control on the layout of the pop-up
> > window.  In right-to-left environments, do right click dialogues also
> flow
> > from right to left?
> > For the sake of generalization, I think we could remove this flag, and
> have
> > the browser determine the direction in which the window will open.
> >
> >>
> >> - You mention that the contents of the popup can be any URL.  How
> >> would you feel if it were restricted to URLs within the extension?  If
> >> the extension really wanted web-hosted content, it could just use an
> >> iframe.
> >
> > I also considered this exact case.  Moles, at least the last time I
> looked,
> > allowed redirection to any page.  I think it would be reasonable to
> restrict
> > this API to extension-only pages.  Should the mole also be restricted in
> > this manner?
>
> Yes, this is our current thinking.  We're still having some debates
> about it, so we haven't updated the mole implementation / docs yet.
>
>
> >> - I'm a little unclear about the need for a user-controllable resize
> >> widget.  Could you give some use cases?
> >
> > The resize widget was added to allow for hosting of dynamic
> > extension-specific search-result pages.  For example, the user expands
> the
> > window, and more results are shown.
>
> Hm.  I'm not convinced that this is worth it to have in the general
> API.  Let's chat about this a bit more.
>
>
> > I found that the window.resizeTo and window.resizeBy did not work in
> Chrome.
> >  Is there another way that we could easily allow the pop-up-hosted
> extension
> > page to control its size dynamically?
>
> This is simply a bug / omission.  There are a few popup window
> behaviors which are blocked generally by Chrome that should be enabled
> for extensions (hiding the address bar for example).
>

Ah, I wasn't aware of that.  I also tried body.resizeTo and body.resizeBy,
and they are disabled in non-extension views.  If those APIs are available
in extension views, then I agree that user-based resizing could be
implemented entirely in JS without the need for this API.  However, since
this may be a viable use-case, should we not include it to make the API
easier to use?  We can discuss this in more detail later today.


>
> In the short term within popups, we can control size similarly to how
> we do within toolstrips and moles.  Just explicitly size the body
> element.
>

>
> >> - In your abuse section, you mention a security concern about
> >> navigating to non-extension pages.  This is something that has already
> >> been addressed by the extensions system.  Privileges are granted by
> >> origin, not by the surface that's being rendered.
> >>
> >> - My take is that the default behavior should be to change its
> >> orientation if it would get clipped by the edge of the screen.  If it
> >> were important to maintain orientation in some cases, I suppose we
> >> could make this an argument.
> >
> > I think that's a reasonable approach.  Looking at the moles right now,
> they
> > do not pop-down if upon expansion they will be clipped by the edge of the
> > screen.  Will they also require this modification?
>
> Yes, although it's less clear what the ultimate behavior should be for
> moles in this case.  Clipping behavior of moles is currently their
> largest unsolved UI issue (the specifics involve when the mole is
> larger than the toolstrip it's originating from).
>
>
> >
> >>
> >> Erik
> >>
> >>
> >> On Wed, Sep 2, 2009 at 5:48 PM, Jeff Timanus <[email protected]>
> >> wrote:
> >> > Hello Chromium-Extension developers & advocates,
> >> > In the interest of allowing for more advanced user-interfaces within
> >> > Chromium extensions, I've put together a proposal for for an API
> >> > allowing
> >> > the display of pop-up windows from within extension views.
> >> > Please see the publicly-shared Google-document here:
> >> >
> >> >
> http://docs.google.com/Doc?docid=0AWTKb4thI6aoZGdzYmpoNXpfMjJnYnZwcnJmMw&hl=en
> >> > Some of the key points I've tried to address:
> >> >  - No modal windows may be displayed.  All pop-up windows must be
> >> > dismissed
> >> > upon interaction outside of their view.
> >> >  - Easy integration with right-to-left environments.
> >> >  - Ease of communication between the pop-up window and the hosting
> >> > extension
> >> > view.
> >> > I look forward to the discussion and review process for this proposal.
> >> > Thanks,
> >> > Jeff
> >> > >
> >> >
> >>
> >> > >>
> >
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Chromium-extensions" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/chromium-extensions?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to