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. 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. >> - 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). 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 -~----------~----~----~----~------~----~------~--~---
