User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20160420141331 Steps to reproduce: 1. User A invites user B to an event. This event has a long title of ~50 characters 2. User B adds this event to his calendar 3. User B clicks on the event in the calendar in order to change his participation Actual results: The dialog opens and fit the title length, so it's very wide and the ok/cancel buttons are hidden at the right of the right, far out of the screen. Cf attached screenshot. Expected results: The dialog should fit the screen width even if the title is too long. It works correctly for the other fields (location, description) or just if user B displays user A calendar and look at this event but in user A calendar.
Thanks for the report and all the others. Confirming. We probably can simply limit the max width of the dialog to that of the main window to avoid this effect.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This patch should fix.
Assignee: nobody → bv1578
Status: NEW → ASSIGNED
Attachment #8759673 - Flags: review?(makemyday)
Comment on attachment 8759673 [details] [diff] [review] patch - v1 Review of attachment 8759673 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for the patch. r=me, but please check the comment below. ::: calendar/base/content/dialogs/calendar-summary-dialog.xul @@ +60,5 @@ > </columns> > <rows> > <row align="top"> > <label value="&read.only.title.label;" class="headline"/> > + <label id="item-title" crop="end"/> Can you add the crop="end" also to item-location and item-category? This properties may result also in widening the dialog. All the others seem to be ok, because the cannot hold content of variable length or we already take care of it.
Attachment #8759673 - Flags: review?(makemyday) → review+
(In reply to MakeMyDay from comment #3) > Can you add the crop="end" also to item-location and item-category? Done. I've also changed the crop attribute for the element item-organizer from "right" to "end" because it should be deprecated according to MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/crop pushed to comm-central: https://hg.mozilla.org/comm-central/rev/33a058a61094
Should we backport this fix?
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
OS: Unspecified → All
Hardware: Unspecified → All
Resolution: --- → FIXED
Target Milestone: --- → 5.1
Comment on attachment 8759969 [details] [diff] [review] patch - v2 Even that issue is kind of an edge case, the patch is simple enough to backport. To be part of 4.7.2, it would need to land on ers45 in the next few days.
Attachment #8759969 - Flags: approval-calendar-esr?(philipp)
Attachment #8759969 - Flags: approval-calendar-esr+
Attachment #8759969 - Flags: approval-calendar-beta?(philipp)
Attachment #8759969 - Flags: approval-calendar-beta+
Attachment #8759969 - Flags: approval-calendar-aurora?(philipp)
Attachment #8759969 - Flags: approval-calendar-aurora+
Pushed to: http://hg.mozilla.org/releases/comm-beta/rev/3a5a6e9f5ba6 http://hg.mozilla.org/releases/comm-esr45/rev/2ee40c158983 The patch is already in aurora.
Target Milestone: 5.1 → 4.7.2
Not seeing the Aurora landing but the approval-calendar-aurora+ flag upsets my search a little, so here the Aurora changeset: https://hg.mozilla.org/releases/comm-aurora/rev/33a058a61094
You need to log in before you can comment on or make changes to this bug.