Confirmed users
586
edits
Fennec/NativeUI/PanZoom: Difference between revisions
Jump to navigation
Jump to search
claim some items to work on
No edit summary |
(claim some items to work on) |
||
| Line 4: | Line 4: | ||
* Some pages like TechCrunch have bad checkerboarding. Cause unknown, possibly due to the Like buttons. | * Some pages like TechCrunch have bad checkerboarding. Cause unknown, possibly due to the Like buttons. | ||
* When zoomed in, scrolling down too far results in checkerboards that don't go away. This is the result of an incorrectly-defined scissor rect in the renderer. | * When zoomed in, scrolling down too far results in checkerboards that don't go away. This is the result of an incorrectly-defined scissor rect in the renderer. | ||
* Sometimes the page size doesn't get picked up by Java and it ends up all wrong, especially when using back and forward. This is due to the hacky method used to query the page size. | * Sometimes the page size doesn't get picked up by Java and it ends up all wrong, especially when using back and forward. This is due to the hacky method used to query the page size. (Kats looking at this) | ||
* Page size is set by monkey patching content CSS. This is not only ugly but may fail if the page overrides it. The correct solution to this is non-e10s SetDisplayPort, coupled with SetCSSViewport (the latter of which works now, but is useless without a display port because it clips at the viewport). | * Page size is set by monkey patching content CSS. This is not only ugly but may fail if the page overrides it. The correct solution to this is non-e10s SetDisplayPort, coupled with SetCSSViewport (the latter of which works now, but is useless without a display port because it clips at the viewport). | ||
* Sometimes the scale gesture detection gets confused and the page ends up very tiny or very big. Cause unknown, possibly due to incorrect interaction between the scale gesture detector and the panning code. | * Sometimes the scale gesture detection gets confused and the page ends up very tiny or very big. Cause unknown, possibly due to incorrect interaction between the scale gesture detector and the panning code. | ||
| Line 16: | Line 16: | ||
* The saved screenshot doesn't always appear in the right part of the page. Page size is not saved. This is because we only save a screenshot, while we actually need to save some more info (page size, etc.) in order to pan and zoom during load. | * The saved screenshot doesn't always appear in the right part of the page. Page size is not saved. This is because we only save a screenshot, while we actually need to save some more info (page size, etc.) in order to pan and zoom during load. | ||
* Chews through battery because it's trying to consistently render at 60 fps regardless of whether work needs to be done. | * Chews through battery because it's trying to consistently render at 60 fps regardless of whether work needs to be done. | ||
* Physics are wrong when overscrolling, particularly diagonally (too long of a delay before bouncing back). | * Physics are wrong when overscrolling, particularly diagonally (too long of a delay before bouncing back). (Kats looking at this) | ||
* Touch event handling is incorrect in some cases | * Touch event handling is incorrect in some cases | ||
** <strike>Under some conditions when two fingers are on the page, removing one will cause the page to snap-pan</strike> (fixed in panzoomfixups patch) | ** <strike>Under some conditions when two fingers are on the page, removing one will cause the page to snap-pan</strike> (fixed in panzoomfixups patch) | ||
** Touch down on a link, pan the page, and then touch up will trigger that link (need to figure out which events should actually be delivered to non-java code) | ** Touch down on a link, pan the page, and then touch up will trigger that link (need to figure out which events should actually be delivered to non-java code) | ||