remove unnecessary observes= from calendar
Categories
(Calendar :: General, task)
Tracking
(Not tracked)
People
(Reporter: mkmelin, Assigned: mkmelin)
Details
Attachments
(1 file, 3 obsolete files)
79.22 KB,
patch
|
mkmelin
:
review+
|
Details | Diff | Splinter Review |
I was looking at observes attribute usage in calendar, and noticed there's apparently been some misunderstanding of how that should be used: if you have a command on the element, you don't need to have observes= too. When command updating happens, that will also take care of enabling/disabling the element.
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
Comment 3•5 years ago
|
||
Comment on attachment 9094868 [details] [diff] [review] bug1583481_cal_observes_attr_cleanup.patch Review of attachment 9094868 [details] [diff] [review]: ----------------------------------------------------------------- Codewise this seems fine to me. One thing to consider: using `observes="foo"` when `foo` is a broadcaster would make that element an observer, which means it will watch some additional attributes, I believe including `disabled`. It doesn't seem we have any more broadcasters, but what you should make sure before pushing this is that the elements that had `observes=` aren't expecting additional attributes.
Assignee | ||
Comment 4•5 years ago
|
||
Thanks, there are only a few commands that have attributes, and looks like those work fine.
Comment 5•5 years ago
|
||
Causes Mochitest (bct) failures locally. Did your look at your own try run?
Assignee | ||
Comment 6•5 years ago
|
||
document.commandDispatcher.updateCommands("calendar_commands") didn't cause calendar/lightning/content/messenger-overlay-sidebar.xul specific (eh..!) calendar_commands commands to get updated...
Assignee | ||
Comment 7•5 years ago
|
||
I think the calendar_commands not working as expected is a bug in Overlays.jsm.
Anyway, I also adjusted the context menu not to show disabled items when not on a calendar, but to hide them instead, like is usual practice for context menus. And dropped the manual logic to adjust the disabled states in the menu, since the command attribute will take care automatically now that it's working.
Comment 8•5 years ago
|
||
Comment on attachment 9097576 [details] [diff] [review] bug1584720_search-textbox_context.patch Review of attachment 9097576 [details] [diff] [review]: ----------------------------------------------------------------- I think you meant to ask Jörg for review? This is in mail/
Comment 9•5 years ago
|
||
Actually it may be the wrong patch, the bug numbers mismatch.
Comment 10•5 years ago
|
||
Comment on attachment 9097576 [details] [diff] [review] bug1584720_search-textbox_context.patch I've already reviewed this one and we landed it ;-) - Yes, wrong patch, we need the update to make the M(bct) pass, see comment #5.
Assignee | ||
Comment 11•5 years ago
|
||
The right patch, fixed and unbitrotted.
Comment 12•5 years ago
|
||
Comment on attachment 9099390 [details] [diff] [review] bug1583481_cal_observes_attr_cleanup.patch Review of attachment 9099390 [details] [diff] [review]: ----------------------------------------------------------------- ::: calendar/base/content/calendar-management.js @@ +503,4 @@ > setupDeleteMenuitem("list-calendars-context-delete", calendar); > + event.target.querySelectorAll(".needs-calendar").forEach(elem => { > + elem.removeAttribute("collapsed"); > + }); Same as next comment @@ +507,2 @@ > } else { > + event.target.querySelectorAll(".needs-calendar").forEach(elem => { Can we just use for..of here? Given we are using an anonymous function anyway I think we can skip the extra function calls.
Assignee | ||
Comment 13•5 years ago
|
||
Made the change. Didn't realize for...of works for querySelectorAll.
Assignee | ||
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/e544df90a3f3
remove unnecessary observes= from calendar. r=Fallen
Updated•5 years ago
|
Description
•