Thanks for your comments, Aaron. 2009/9/22 Aaron Boodman <[email protected]>
> Hi Jeff, > > Sorry for the delayed reply as well. Some thoughts. > > Close behavior > =========== > Your proposal says that the popup closes when another window is > focused. I think that when the developer opens the popup, they should > specify one of two close behaviors: close-on-blur and > close-on-mouseout. Close-on-blur would be like a normal OS menu: the > popup closes when you click somewhere that isn't the menu or > toolstrip. Close-on-mouseout would be the same but with mouseover > (with some delay for mouse inaccuracy). > > I think this is especially important since we don't have an event API > that would allow developers to implement this behavior. There's no way > for them to detect clicks outside the toolstrip and popup area. > I like your idea. I think it should be added to the design. > > Positioning > ========= > It seems like the y coordinate for the position is not necessary. I > think we want to control the vertical positioning wrt the toolstrip. > The need for the y coordinate, or dom object, is that with this extension, as well as moles, a pop-up can be launched from outside of a toolstrip: Either in a mole, or a pop-up itself. A pop-up could also be launched from a tab-contents view that has been navigated to an extension resource. My intent is that each extension view is allowed to have one pop-up active. This allows for recursive menus, etc. A pop-up that can spawn nested pop-ups to navigate a heirarchy. Given this, I don't think that the API should be specifically bound to toolstrip behaviour. > > > Integration with browser actions > ======================== > We need some. I think that my preference is that browser action popups > are declarative (via the manifest) not programmatic. > > API > === > * Agree with erikkay that only extension paths should be allowed, not any > URL. > * It should be possible to return the popup Window reference > synchronously (like window.open() in the DOM) instead of via a > callback > > > - a > > 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. > > > >> > >> - 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? > > > >> > >> - 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. > > 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? > > > >> > >> - 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? > > > >> > >> 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 -~----------~----~----~----~------~----~------~--~---
