> 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.
I think it's desired to be able to make a drop-down feel like a natural continuation of an element within the toolbar (think combo-buttons) in which case you either need to specify the y coordinate, or have a way to anchor to a specified DOM element. The former is probably easier and more flexible. Cheers, Jói On Tue, Sep 22, 2009 at 2:31 AM, Aaron Boodman <[email protected]> wrote: > > 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. > > 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. > > > 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 -~----------~----~----~----~------~----~------~--~---
