Closed Bug 787060 Opened 11 years ago Closed 11 years ago
Open in new tab from bookmarks will open the new tab in URL but content of page remains the old tab
Build ID: 17.0a2 (2012-08-29) Aurora Channel Device: Galaxy Nexus OS: Android 4.0.4 Steps to reproduce: 1. Open Fennec 2. Go to Bookmark -> Long press on a different page than the one opened already 3. After the message new tab opened is display press back 4. Look at the URL and page content 5 Rotate the device Expected result: - the count no of tabs should be increased with 1 - the URL and page content should be from the initial page Actual result: - the URL is changed being the one from the new tab opened - page content is the one from the initial page - after rotating the page content is refreshed and it the one from the tab opened in new tab - please see video : https://www.youtube.com/watch?v=lIfxBc3HAgw
This seems like a composition pause/resume bug, moving to graphics component.
Component: Awesomescreen → Graphics, Panning and Zooming
Actually this doesn't seem to be a composition pause/resume bug. The new tab is created and selected, and when we hide the awesomescreen and resume the compositor we do call nsWindow::RedrawAll. This trickles through to mWidgetListener->PaintWindow but for some reason this doesn't actually do a paint. I'll need to trace a bit further in.
It looks like it bails out at this point in the code: http://hg.mozilla.org/mozilla-central/file/d1a5d4cda6ac/layout/base/nsPresShell.cpp#l5291 The stack at that point looks like this: #0 PresShell::Paint (this=0x5eac1120, aViewToPaint=0x65a5b8e0, aDirtyRegion=..., aType=nsIPresShell::PaintType_Composite, aWillSendDidPaint=false) at /Users/kats/zspace/mozilla-git/layout/base/nsPresShell.cpp:5290 #1 0x63ab1868 in nsViewManager::Refresh (this=0x65a57ca0, aView=0x65a5b8e0, aRegion=..., aWillSendDidPaint=<optimized out>) at /Users/kats/zspace/mozilla-git/view/src/nsViewManager.cpp:372 #2 0x63ab2856 in nsViewManager::PaintWindow (this=0x65a57ca0, aWidget=0x606283e0, aRegion=..., aSentWillPaint=<optimized out>, aWillSendDidPaint=false) at /Users/kats/zspace/mozilla-git/view/src/nsViewManager.cpp:709 #3 0x63ab0dc8 in nsView::PaintWindow (this=<optimized out>, aWidget=0x606283e0, aRegion=..., aSentWillPaint=<optimized out>, aWillSendDidPaint=false) at /Users/kats/zspace/mozilla-git/view/src/nsView.cpp:1034 #4 0x63fc1fe4 in nsWindow::DrawTo (this=0x606283e0, targetSurface=0x607b0400, invalidRect=...) at /Users/kats/zspace/mozilla-git/widget/android/nsWindow.cpp:1002 #5 0x63fc2152 in nsWindow::DrawTo (this=0x60627d60, targetSurface=0x607b0400, invalidRect=...) at /Users/kats/zspace/mozilla-git/widget/android/nsWindow.cpp:1050 #6 0x63fc22f6 in OnDraw (ae=0x616a4a00, this=0x60627d60) at /Users/kats/zspace/mozilla-git/widget/android/nsWindow.cpp:1102 #7 nsWindow::OnDraw (this=0x60627d60, ae=0x616a4a00) at /Users/kats/zspace/mozilla-git/widget/android/nsWindow.cpp:1064 #8 0x63fc45bc in nsWindow::OnGlobalAndroidEvent (ae=0x616a4a00) at /Users/kats/zspace/mozilla-git/widget/android/nsWindow.cpp:863 #9 0x63fb71f6 in nsAppShell::ProcessNextNativeEvent (this=<optimized out>, mayWait=<optimized out>) at /Users/kats/zspace/mozilla-git/widget/android/nsAppShell.cpp:629 #10 0x63fc791c in nsBaseAppShell::DoProcessNextNativeEvent (this=0x5ea62660, mayWait=<optimized out>, recursionDepth=0) at /Users/kats/zspace/mozilla-git/widget/xpwidgets/nsBaseAppShell.cpp:139 #11 0x63fc79ee in nsBaseAppShell::OnProcessNextEvent (this=0x5ea62660, thr=0x5ea510f0, mayWait=<optimized out>, recursionDepth=0) at /Users/kats/zspace/mozilla-git/widget/xpwidgets/nsBaseAppShell.cpp:298 #12 0x641af4f6 in nsThread::ProcessNextEvent (this=0x5ea510f0, mayWait=<optimized out>, result=0x5d9d88bf) at /Users/kats/zspace/mozilla-git/xpcom/threads/nsThread.cpp:586 #13 0x6417bcde in NS_ProcessNextEvent_P (thread=0x5ea510f0, mayWait=<optimized out>) at /Users/kats/zspace/mozilla-git/obj-android-debug/xpcom/build/nsThreadUtils.cpp:220 #14 0x64073906 in mozilla::ipc::MessagePump::Run (this=0x5ea532e0, aDelegate=0x5ea7f0e0) at /Users/kats/zspace/mozilla-git/ipc/glue/MessagePump.cpp:117 #15 0x641dcac2 in MessageLoop::RunInternal (this=0x5ea7f0e0) at /Users/kats/zspace/mozilla-git/ipc/chromium/src/base/message_loop.cc:208 #16 0x641dcb20 in RunHandler (this=0x5ea7f0e0) at /Users/kats/zspace/mozilla-git/ipc/chromium/src/base/message_loop.cc:201 #17 MessageLoop::Run (this=0x5ea7f0e0) at /Users/kats/zspace/mozilla-git/ipc/chromium/src/base/message_loop.cc:175 #18 0x63fc71ea in nsBaseAppShell::Run (this=0x5ea62660) at /Users/kats/zspace/mozilla-git/widget/xpwidgets/nsBaseAppShell.cpp:163 #19 0x63e93a40 in nsAppStartup::Run (this=0x607ff6a0) at /Users/kats/zspace/mozilla-git/toolkit/components/startup/nsAppStartup.cpp:273 #20 0x635e076a in XREMain::XRE_mainRun (this=0x5d9d8ae4) at /Users/kats/zspace/mozilla-git/toolkit/xre/nsAppRunner.cpp:3800 #21 0x635e1e86 in XREMain::XRE_main (this=0x5d9d8ae4, argc=<optimized out>, argv=0x5ea6b048, aAppData=<optimized out>) at /Users/kats/zspace/mozilla-git/toolkit/xre/nsAppRunner.cpp:3877 #22 0x635e1fe2 in XRE_main (argc=7, argv=0x5ea6b048, aAppData=0x5aaccc2c, aFlags=<optimized out>) at /Users/kats/zspace/mozilla-git/toolkit/xre/nsAppRunner.cpp:3953 #23 0x635e7a60 in GeckoStart (data=0x5bf45e08, appData=0x5aaccc2c) at /Users/kats/zspace/mozilla-git/toolkit/xre/nsAndroidStartup.cpp:73 #24 0x5aab3028 in Java_org_mozilla_gecko_GeckoAppShell_nativeRun (jenv=0x5beea218, jc=<optimized out>, jargs=0x25e00005) at /Users/kats/zspace/mozilla-git/mozglue/android/APKOpen.cpp:983 #25 0x4073fe34 in dvmAsmAltInstructionStart () from /Users/kats/android/jdb/moz-gdb/lib/01466E640801401C/system/lib/libdvm.so #26 0x4073fe34 in dvmAsmAltInstructionStart () from /Users/kats/android/jdb/moz-gdb/lib/01466E640801401C/system/lib/libdvm.so Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Adding :mattwoodrow - is this possibly a DLBI regression? It doesn't seem to happen on 15 or 16. In a nutshell what seems to be happening is that we change the content (selecting a newly created tab) while the window is invisible and the compositor is paused. The new tab triggers widget invalidations via the refresh driver, which are dropped on the floor at . Later, the composition is resumed when the window becomes visible again, and we trigger a full redraw  which ends up not drawing anything because of the code in comment #3.  http://hg.mozilla.org/mozilla-central/file/d1a5d4cda6ac/widget/android/nsWindow.cpp#l1087  http://hg.mozilla.org/mozilla-central/file/d1a5d4cda6ac/widget/android/nsWindow.cpp#l929
Yes, this sounds like a regression from my patches. Basically, a gecko paint event (like is being created from OnDraw()) now only composites the existing layer tree to the window, it doesn't actually draw anything into the layers. In the case where we have shadow layers, the composite is already being handled on a different thread, so OnDraw() is essentially a nop. It can probably be removed entirely once this stabilizes. RedrawAll needs to instead trigger the Paint call here , which is triggered by nsRefreshDriver::Notify. I'd suggest calling nsViewManager::InvalidateView() which will schedule a view manager flush. Alternatively you can call nsIView::SetForcedRepaint(true) which will trigger a synchronous repaint from within OnDraw() () which would mimic the old behaviour.  http://mxr.mozilla.org/mozilla-central/source/view/src/nsViewManager.cpp#438  http://mxr.mozilla.org/mozilla-central/source/view/src/nsViewManager.cpp#345
This seems to fix the problem. Pushed to try at https://tbpl.mozilla.org/?tree=Try&rev=d44d3ef75142
Attachment #658129 - Flags: review?(matt.woodrow)
11 years ago
Assignee: nobody → bugmail.mozilla
Attachment #658129 - Flags: review?(matt.woodrow) → review+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18
I can still reproduce this issue on the latest Nightly build. Reopening bug
What is the latest build? Are you sure your build is up to date due to the updater breakage?
(In reply to Aaron Train [:aaronmt] from comment #10) > What is the latest build? Are you sure your build is up to date due to the > updater breakage? I forgot to post the environment, sorry. Here is a screenshot from about:firefox http://s9.postimage.org/ooew7urel/device_2012_09_12_170520.png I am pretty sure that the latest build was correctly installed. I am always able to reproduce this issue on it. -- Firefox 18.0a1 (2012-09-12) Device: Galaxy Note OS: Android 4.0.4
However it works like a charm on Galaxy Nexus. Perhaps my Note is not in a good shape today. Closing bug as verified fixed on: Firefox 18.0a1 (2012-09-12) Device: Galaxy Mexus OS: Android 4.1.1
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.