GNOME Bugzilla – Bug 738725
Regression in dateMenu.js
Last modified: 2015-02-26 23:05:56 UTC
BUG: Opening the date menu for the first time results in a blank Day, Month, Date and Year but opening the second time makes it appear. STEPS TO REPRODUCE: Open date menu for the first time, then open for a second time. Can reproduce by restarting GNOME and testing again. VERSION: 3.14-1
It seems the label is painted black the first time you open the menu for some reason. If you look really closely you can see the text as completely black.
Yeah, I can see it if I look down at the monitor (not at normal viewing angles). Weird. If you place the code inside that 'if(open)' section before the this.menu.connect('open-state-changed'... then it draws the date the first time correctly.
Created attachment 289233 [details] [review] Fixed _isToday(date) call Open the calendar and click on any day in the week that is above/below. This causes the button up the top to become non-reactive.
Review of attachment 289233 [details] [review]: Good catch. Please separate subject (max ~70 characters) from the body in the commit message, otherwise good.
This is unrelated to the original bug report, though.
@Jasper, sorry about that, I noticed this while trying to find the first one. Should I open a new bug and put it there?
No, this is fine - the bug should just be left open until the original problem is fixed.
Created attachment 289242 [details] [review] Set label to visible when updated visibility It seems like the call works in 'open-changed...' but the visibility of the button is overwritten by something else later in the constructor. Putting the _date.visible to true makes it appear first time. This is probably the wrong place to set the visibility but couldn't think of anything more clever.
Review of attachment 289242 [details] [review]: This sets items' visibility depending on whether the user configured any calendars. It doesn't make any sense to hide the date label when there are no calendars.
Comment on attachment 289233 [details] [review] Fixed _isToday(date) call Pushed acn patch with fixed up commit message.
Created attachment 290059 [details] [review] Construct a button and give it a label. Thanks Florian. That previous patch was a stupid one and only worked because I accidentally left some code in there from before. What would be wrong with constructing the button with the date label then updating it on each open, something like what I attached? I'm not sure how the scope works when passing a function as an argument.
What happens when the user comes back in a few days and clicks the button?
(In reply to comment #12) > What happens when the user comes back in a few days and clicks the button? Isn't that still handled in the 'on-opened' code?
(In reply to comment #12) > What happens when the user comes back in a few days and clicks the button? The label is still updated each time the menu is opened. I had stumbled upon this as well, because the code in the patch now hides this fairly well ...
I'm curious why your patch fixes the issue then, because the only difference is that we also set the label on startup, but also when the user clicks the button.
(In reply to comment #11) > What would be wrong with constructing the button with the date label then > updating it on each open, something like what I attached? You could just use a pseudo label like 'Hack: make sure the label is shown' (no point in setting the actual date when it will always be overridden on open). It would still be interesting to figure out why this is happening.
I was hoping you guys might know why it works. I can sink some more time into it in a few more weeks and *maybe* come up with a solution (but horribly unlikely).
*** Bug 741516 has been marked as a duplicate of this bug. ***
*** Bug 741656 has been marked as a duplicate of this bug. ***
Accidentally fixed when implementing the new calendar/notification design.