Confirmed users
269
edits
No edit summary |
m (rv for and on behalf of Biesi) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 17: | Line 17: | ||
* Every time content geometry changes in a way that affects the positioning or clipping of a plugin, we reflect that change by repositioning the clipping and plugin widgets and changing the size of the clipping widget. | * Every time content geometry changes in a way that affects the positioning or clipping of a plugin, we reflect that change by repositioning the clipping and plugin widgets and changing the size of the clipping widget. | ||
* To scroll, we do in-window bitblits of the main window and reconfigure the plugin/clipping widgets. | * To scroll, we do in-window bitblits of the main window and reconfigure the plugin/clipping widgets. | ||
This will require hooking up all viewmanagers in a window into a single tree. Currently view managers in content subshells of chrome shells are not hooked up to their parent. | |||
To scroll a page where the plugins must move, here's how it could work: | To scroll a page where the plugins must move, here's how it could work: | ||
Line 39: | Line 41: | ||
* Will this be acceptable for plugins? | * Will this be acceptable for plugins? | ||
* How will various platforms cope, especially Cocoa, where scrollbars are native widgets? | * How will various platforms cope, especially Cocoa, where scrollbars are native widgets? | ||
* This will cause some problems for accessibility, which currently depends on native widgets being attached to the browser content window, but Aaron thinks he can deal with it. | |||
It looks like Cocoa might be able to paint scrollbars via NSSliderCell. | It looks like Cocoa might be able to paint scrollbars via NSSliderCell. |