2009/9/22 Jói Sigurðsson <[email protected]>: >> 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.
I understand where you're coming from here, but this feels a bit fragile and hard to use (computing the right x, y position can be tricky) for this case. Attached to the DOM element seems like it's something that would be less error-prone for the developer. I think the x,y case makes sense for context-menu applications where the location is easy to figure out (it's just where you clicked), but note my other comment to Jeff about having a different API for context menus. One other bit of pushback is that while I like the idea of trying to make popups that can feel like they're connected to the UI of an element in the toolstrip, I'd like us to start with a simpler implementation that intentionally looks a bit more detached (I have some mocks I can show you on this front). Once we get this nailed and looking good, then we could revisit this. I'm not saying we shouldn't do it, just thinking about logical implementation progression. Erik > > 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 -~----------~----~----~----~------~----~------~--~---
