Views content disappearing if deleted and recreated exactly the same |
||||||
Issue descriptionVersion: 52 (I will get the exact sync point later) OS: Linux I saw some very strange behaviour while working on https://codereview.chromium.org/1983803002/ (see Patch Set 15 and earlier) where deleting some views (using RemoveAllChildren(true)) and then recreating the exact same child views resulted in all the children being invisible, some of the time. Specifically, I modified SubtleNotificationView with the logic (simplified): void SubtleNotificationView::SetText(const base::string16& text) { RemoveAllChildren(true); views::Label* label = new Label(text); AddChildView(label); } I found that: - If I call SetText with the exact same string every time, it's fine. It just looks like nothing changed. - If I call SetText with different text to last time, it's fine; it changes to the new text. - BUT, once I have called SetText with two different texts, from now on, whenever I call SetText with the same string as last time, all the content is invisible. - The content becomes visible again upon changing the text. It doesn't matter if I'm just creating a single label, or a whole Views hierarchy in there (e.g., SubtleNotificationView creates multiple labels in a BoxLayout with borders). All of the contents goes invisible. I've stripped down the code to deleting and recreating a single Label, as shown above, and it still happens. This is baffling because I am not doing any special cases in my code that check for whether the string is the same. I don't know why Views would behave any differently based on the contents of the string matching against the contents of a previous Label that has been previously deleted. No idea, but it warrants further investigation. In the mean time, I am working around this in Patch Set 16 of that CL by simply checking whether the string is the same, and taking no action in that case (which is good to do anyway).
,
Jul 21 2016
If the code is only as you have above, then I could see it being problematic. In particular I don't see layout being called on SubtleNotificationView, so that label will be sized to 0x0 and not visible. I would expect SetText to also trigger a layout. If you aren't doing a layout, then this should be closed.
,
Jul 22 2016
#2 Thanks for looking. It seems you're right; calling Layout() on SubtleNotificationView::UpdateContent makes the problem go away. Still, I'm confused as to why this magically works if I update the Label's text to any text other than exactly what I already had there. Does it perhaps do its own layout in this case? Feel free to close if you think this is not an issue.
,
Jul 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9e9ba79e590df945401cb66e48f4ec632874a309 commit 9e9ba79e590df945401cb66e48f4ec632874a309 Author: mgiuca <mgiuca@chromium.org> Date: Mon Jul 25 01:33:07 2016 SubtleNotificationView: Layout after changing text; ensure it's visible. This is just a precaution as it doesn't seem to have any effect right now, but not doing this has caused trouble in the past (see crbug.com/613324). BUG=613324 Review-Url: https://codereview.chromium.org/2175583002 Cr-Commit-Position: refs/heads/master@{#407396} [modify] https://crrev.com/9e9ba79e590df945401cb66e48f4ec632874a309/chrome/browser/ui/views/subtle_notification_view.cc
,
Nov 3 2016
Fixed the empty status.
,
Nov 6 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 1
,
Nov 27
***UI Mass Triage *** Adding labels for expert review. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by cbiesin...@chromium.org
, Jul 21 2016