Warning: Property contained reference to invalid variable

RESOLVED FIXED in 4.0.0.1

Status

Calendar
Calendar Views
--
trivial
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: Decathlon, Assigned: Decathlon)

Tracking

Sunbird 1.0b1
4.0.0.1

Details

Attachments

(1 attachment, 1 obsolete attachment)

1.56 KB, patch
Decathlon
: review+
Details | Diff | Splinter Review
(Assignee)

Description

3 years ago
In month view a warning message appears in the console when is being selected a daybox that belongs to another month.
(Assignee)

Comment 1

3 years ago
Created attachment 8547143 [details] [diff] [review]
patch - v1

A variable escaped form the second revision of the patch in bug 985114.
Attachment #8547143 - Flags: review?(richard.marti)
Comment on attachment 8547143 [details] [diff] [review]
patch - v1

r+ with fixing this also in window[systemcolors] {}.
Attachment #8547143 - Flags: review?(richard.marti) → review+
(Assignee)

Comment 3

3 years ago
Created attachment 8547153 [details] [diff] [review]
patch - v2

It's always better to check on mxr too ;-)

What is the status on comm-central? Is it possible to push the patch or should I set the checkin-needed keyword?
Attachment #8547143 - Attachment is obsolete: true
Attachment #8547153 - Flags: review+
It's possible after starring the failures. See https://wiki.mozilla.org/Sheriffing/How:To:Comm-central
(Assignee)

Comment 5

3 years ago
I've never understood that stuff. If one has to wait for the starred oranges (at least one) on the previous push, I can't explain why so many people push patches when the previous push has not been starred at all yet (e.g. like now 2015-01-11 02:30 PST). Am I missing something?
On the other hand, since the process building+run tests is rather long, the timing window to push your patch is minimum because someone else is waiting to push another patch on the tree and, in theory, you should wait for starring the oranges that will come on this new push under build (a process that takes hours and, with oranges starred, sometimes even days).
I see that patches like this one are not a problem for the failures, but they should follow the rule too. Shouldn't they?
But I see this is not the place to talk about that.
Keywords: checkin-needed
I think there is a bug that starring on treeherder is not taken over on tbpl. Were you checking on treeherder? I think Sylvestre just broke the rules in this case and its an exception, but I usually set checkin-needed myself and wait for more patches to crop up so we can push a few at once. In theory, all patches go through the same rules, there is no exception for minor patches.
(Assignee)

Comment 7

3 years ago
(In reply to Philipp Kewisch [:Fallen] from comment #6)
> I think there is a bug that starring on treeherder is not taken over on
> tbpl.

Ah, OK. Now I see the difference, it seemed strange that lately it took so long for starring failures.

> but I usually set checkin-needed
> myself and wait for more patches to crop up so we can push a few at once.

Now could be a right moment for pushing (all starred on treeherder and no build in progress), but I leave the checkin-needed if you prefer to have more patches to push at once.

Comment 8

3 years ago
https://hg.mozilla.org/comm-central/rev/0bb412cd7f81

Updated

3 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 3.6
Target Milestone: 3.6 → 4.0
You need to log in before you can comment on or make changes to this bug.