On Tue, Sep 22, 2009 at 8:27 AM, Jeff Timanus <[email protected]> wrote: > > > 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?
Not really. You could imagine a specific menu API that just took lists of menu items. It could handle submenus, dimming, etc. and could be build to have native look and feel. If build this way, developers would have much less code to implement, and menus would behave in a more consistent way across extensions. >> >> - 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. I haven't tried resizeTo and resizeBy. I simply change the CSS width property. Take a look at chrome/test/data/extensions/samples/resizer. Erik >> 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 -~----------~----~----~----~------~----~------~--~---
