There's something really fishy going on with ecore's main loop and the way the updates are processed for these two tests. In short, when the tests are run in DumpRenderTree no repaint rectangle is registered, so we get entirely gray images (it is possible to see a darkened scroll bar in cache-2.html) with no white rectangle whatsoever. If anyone is willing to debug this further, simply calling `bt' on gdb on WebCore::Element::offsetTop is normally enough for things to be processed and rendered correctly, which indicates a timing bug somewhere in the call stack. The correct processing order is `WebCore::Element::offsetTop() -> [...] -> _ecore_main_loop_iterate_internal() -> _ecore_timer_expired_timers_call() -> [...] -> _ecore_main_loop_iterate_internal() -> _ecore_idle_enterer_call() -> [...] -> _ewk_view_smart_calculate() -> [...] -> WebCore::RenderLayer::addBlockSelectionGapsBounds() -> [...] -> another call to WebCore::Element::offsetTop()'. However, the normal flow ends up being `WebCore::Element::offsetTop() -> [...] -> _ecore_main_loop_iterate_internal() -> _ecore_timer_expired_timers_call() -> [...] -> another call to WebCore::Element::offsetTop()' or `WebCore::Element::offsetTop() -> [...] -> another call to WebCore::Element::offsetTop()' depending on how long it takes between each call to offsetTop(). It is essential that _ewk_view_smart_calculate() is called after the first call to offsetTop(), since it is responsible for calling addBlockSelectionGapsBounds() which later makes it possible for the repaint rectangle region to be added for later processing and painting.
Closing this bug because the EFL port has been removed from trunk. If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.