New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 613324 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Views content disappearing if deleted and recreated exactly the same

Project Member Reported by mgiuca@chromium.org, May 19 2016

Issue description

Version: 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).
 
Components: Internals>Views

Comment 2 by sky@chromium.org, Jul 21 2016

Owner: sky@chromium.org
Status: (was: Untriaged)
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.

Comment 3 by mgiuca@chromium.org, 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.
Project Member

Comment 4 by bugdroid1@chromium.org, 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

Status: Available
Fixed the empty status.
Project Member

Comment 6 by sheriffbot@chromium.org, Nov 6 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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
Status: Assigned (was: Untriaged)
Labels: Hotlist-DesktopUIToolingRequired Hotlist-DesktopUIChecked
***UI Mass Triage ***
Adding labels for expert review.

Sign in to add a comment