Open Bug 959132 Opened 10 years ago Updated 1 year ago

Assertion Can only call this on frames that have been reflowed while searching on youtube.com

Categories

(Core :: Layout: Text and Fonts, defect, P4)

29 Branch
x86_64
Windows 7
defect

Tracking

()

People

(Reporter: 06needhamt, Unassigned)

References

()

Details

(Keywords: assertion, platform-parity, Whiteboard: [platform-rel-Youtube])

Attachments

(3 files, 3 obsolete files)

Attached image reflow.png (obsolete) —
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140113093311

Steps to reproduce:

Go on www.youtube.com by typing it in the address bar 
note see bug 958976


Actual results:

error message on search

Assertion Can only call this on frames that have been reflowed.


Expected results:

The search should have completed sucessfully
See Also: → 958976
Attached file reflow.txt (obsolete) —
I'm not able to reproduce the issue with the latest FF29.

Do you have better STR?

In addition, could you make a test with a fresh profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Flags: needinfo?(06needhamt)
Component: General → Untriaged
Product: Core → Firefox
It does not do it now but bug 958976 still occurs hope this helps
Flags: needinfo?(06needhamt)
And Just to clarify i am using nightly built today 13/01/2014
what is an str?
Flags: needinfo?(epinal99-bugzilla)
STR = Steps To Reproduce
Flags: needinfo?(epinal99-bugzilla)
no thats all i did but as i said in the previous comment see bug 958976 for whats happening now as this is not happening now
The path goes to C:\mozilla-source. Do you have the Mozilla developer tools installed?
Flags: needinfo?(06needhamt)
yes i do i downloaded it from https://people.mozilla.org/~rvandermeulen/MozillaBuildSetup1.9.0pre.exe.
Is that correct or do i need something else?
Flags: needinfo?(06needhamt) → needinfo?(sjw)
So you can't reproduce this bug with normal nightly build?
Flags: needinfo?(sjw) → needinfo?(06needhamt)
I could reproduce with 12.01.2014 build but not yesterdays 13.01.2014 build and i am currently updating and rebuilding so i will let you know about today's build hope this helps 
and just to clarify i am building with MVC 10 and --enable-debug
Flags: needinfo?(06needhamt)
Noticed an error in steps to reproduce

Updated Steps to reproduce:

Go on www.youtube.com by typing it in the address bar 
Search for anything
note see bug 958976


Actual results:

error message on search

Assertion Can only call this on frames that have been reflowed.


Expected results:

The search should have completed sucessfully
So this is not a Firefox bug. But I've no idea which Product...
Flags: needinfo?
Attached image Updated Error message (obsolete) —
This happens again on today's build 14.01.2014 i have attached a screenshot of the error message hope this helps
Attachment #8359161 - Attachment is obsolete: true
Attached file reflow2.txt
Updated Console log
Attachment #8359162 - Attachment is obsolete: true
Flags: needinfo?
Please do not delete this needinfo?-flag. It's to find someone who knows more about this bug.
Flags: needinfo?
Tested in the latest version of the Nightly build 29.0a1 (2014-01-19)and unable to reproduce. Could you please add the exact steps to reproduce the same error message
Flags: needinfo?(06needhamt)
Still happens for me when i type any letter into the search box  on youtube.com home page see screenshot of exact error message
Attachment #8359856 - Attachment is obsolete: true
Flags: needinfo?(06needhamt)
Are you using the official Firefox build or a custom version built by you?
Custom build with --enable-debug
this is does not occur in today's build 29/01/2013
The error has started to occur again in today's build 31/01/2014 using the same steps to reproduce as before on windows 8.1 64bit. Hope this helps
Still occurs in 07/02/2014 build
I can't reproduce the assertion on Linux using the str in comment 12.
Can you get the stack for the assertion using a debugger?
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Text
Ever confirmed: true
Flags: needinfo? → needinfo?(06needhamt)
Product: Firefox → Core
I did encounter this assertion in a different bug though with the stack:

###!!! ASSERTION: Can only call this on frames that have been reflowed: ...
nsTextFrame::PaintText [layout/generic/nsTextFrame.cpp:3274]
nsDisplayText::Paint [layout/generic/nsTextFrame.cpp:4556]
mozilla::FrameLayerBuilder::PaintItems
mozilla::FrameLayerBuilder::DrawThebesLayer
mozilla::layers::ClientThebesLayer::PaintBuffer
mozilla::layers::ClientThebesLayer::PaintThebes
mozilla::layers::ClientThebesLayer::RenderLayer
mozilla::layers::ClientContainerLayer::RenderLayer
mozilla::layers::ClientContainerLayer::RenderLayer
mozilla::layers::ClientLayerManager::EndTransactionInternal
mozilla::layers::ClientLayerManager::EndTransaction
nsDisplayList::PaintForFrame
nsLayoutUtils::PaintFrame
PresShell::Paint
nsViewManager::ProcessPendingUpdatesPaint
nsViewManager::ProcessPendingUpdatesForView
nsViewManager::WillPaintWindow
nsView::WillPaintWindow
[...]

I think a few calls got inlined at the top there... namely:
PaintText -> MeasureCharClippedText -> InitializeForDisplay -> GetTrimmedOffsets
http://hg.mozilla.org/mozilla-central/annotate/0085a162499f/layout/generic/nsTextFrame.cpp#l2642

So my theory is that we interrupted the reflow, leaving a bunch of
unreflowed text frames in the frame tree and then we got this paint request.
It seems to me this is something we need to cope with and I made this
tentative fix:

nsTextFrame::BuildDisplayList(nsDisplayListBuilder*   aBuilder,
                               const nsRect&           aDirtyRect,
                               const nsDisplayListSet& aLists)
 {
-  if (!IsVisibleForPainting(aBuilder))
+  if (!IsVisibleForPainting(aBuilder) ||
+      (GetStateBits() & NS_FRAME_FIRST_REFLOW)) {
     return;
+  }
Keywords: assertion, pp
Priority: -- → P4
Attached patch wipSplinter Review
The tentative fix if you want to try it out...
Comment on attachment 8384295 [details] [diff] [review]
wip

Is this the result of interruptible reflow?
(Or if you can't reproduce the bug reliably, I guess you couldn't tell by turning it off?)
i can still reproduce as of todays build
Flags: needinfo?(06needhamt)
platform-rel: --- → ?
Whiteboard: [platform-rel-Youtube]
platform-rel: ? → ---
This assertion also shows up consistently in the editor/reftests/caret_on_presshell_reinit-2.html reftest.

ASSERTION: Can only call this on frames that have been reflowed: '!(GetStateBits() & NS_FRAME_FIRST_REFLOW) || (GetParent()->GetStateBits() & NS_FRAME_TOO_DEEP_IN_FRAME_TREE)', file /home/worker/workspace/build/src/layout/generic/nsTextFrame.cpp, line 2936

Here's a stack from a webrender-enabled build, but it happens with WR disabled as well (hence the asserts-if annotations on the reftest).

#01: PropertyProvider::InitializeForDisplay [layout/generic/nsTextFrame.cpp:3684]
#02: nsTextFrame::PaintText [layout/generic/nsTextFrame.cpp:7001]
#03: nsDisplayText::RenderToContext [gfx/thebes/gfxContext.h:574]
#04: nsDisplayText::Paint [gfx/thebes/gfxContext.h:653]
#05: mozilla::FrameLayerBuilder::PaintItems [layout/painting/FrameLayerBuilder.cpp:6073]
#06: mozilla::FrameLayerBuilder::DrawPaintedLayer [layout/painting/FrameLayerBuilder.cpp:6245]
#07: mozilla::layers::WebRenderPaintedLayer::UpdateImageClient [gfx/src/nsRegion.h:75]
#08: mozilla::layers::WebRenderPaintedLayer::RenderLayer [gfx/layers/wr/WebRenderPaintedLayer.cpp:137]
#09: mozilla::layers::WebRenderContainerLayer::RenderLayer [gfx/layers/wr/WebRenderContainerLayer.cpp:132]
#10: mozilla::layers::WebRenderLayerManager::EndTransactionInternal [gfx/layers/wr/WebRenderLayerManager.cpp:214]
#11: nsDisplayList::PaintRoot [layout/painting/nsDisplayList.cpp:2291]
#12: nsLayoutUtils::PaintFrame [mfbt/RefPtr.h:129]
#13: mozilla::PresShell::Paint [layout/base/PresShell.cpp:6468]
#14: nsDOMWindowUtils::UpdateLayerTree [gfx/src/nsRegion.h:75]
#15: NS_InvokeByIndex
#16: CallMethodHelper::Call [js/xpconnect/src/xpcprivate.h:781]
#17: XPCWrappedNative::CallMethod [js/xpconnect/src/XPCWrappedNative.cpp:1282]
#18: XPC_WN_CallMethod [js/xpconnect/src/XPCWrappedNativeJSOps.cpp:966]
#19: js::CallJSNative [js/src/jscntxtinlines.h:293]
#20: js::InternalCallOrConstruct [js/src/vm/Interpreter.cpp:470]
#21: js::jit::DoCallFallback [js/src/jit/BaselineIC.cpp:2552]
#22: ??? (???:???)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.