Closed Bug 1151440 Opened 9 years ago Closed 9 years ago

Choose a color not responsive when creating a New calendar in Lightning 4.0b1

Categories

(Calendar :: General, defect)

Lightning 4.0.0.1
x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
4.0.0.1

People

(Reporter: walts48, Assigned: mmecca)

References

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150330154247

Steps to reproduce:

Select Calendar tab
Right-click on Home
Select "New Calendar..."
Select "On My Computer" from the Create New Calendar window
Click "Next"
Enter a name in the "Name:" field
Click the Color button



Actual results:

Choose a color dialog box opens
Choose a color pop-up dialog not responding to any input.
Click the "x" on the Create New Calendar window to cancel creation of a new calendar


Expected results:

Should have been able to select the color in any way possible.
Is there any message in the error console (ctrl+shift+j)?
(In reply to MakeMyDay from comment #1)
> Is there any message in the error console (ctrl+shift+j)?

All I see on Start-up of Thunderbird 38.0b1 is;

Timestamp: 04/06/2015 06:03:38 PM
Warning: Use of Mutation Events is deprecated. Use MutationObserver instead.
Source File: chrome://calendar/content/widgets/calendar-widgets.xml
Line: 496

Nothing appears in the Error Console, after I clear the Error Console, and then try to create a new calendar.
We use the color picker from the OS/Desktop environment. On what distribution / desktop environment are you (I gues you're on Linux 64 bit based on your browser signature in you report)?
Flags: needinfo?(schw01)
OS: All → Linux
Hardware: All → x86_64
Target Milestone: --- → 4.0
Why is the color picker a drop down with a bunch of colored squares with Lightning 3.3.3, and a separate Choose a Color window, with a color circle, eyedropper under that, a Hue, Saturation and Value column with a Color Name field under that and a Red, Green and Blue column if you use the color picker from the OS/Desktop environment?

Choosing a color works in Lightning 3.3.3.

Anyway I am using Kubuntu 14.10 and the KDE 4.14.1 desktop environment.
Flags: needinfo?(schw01)
Thank you for the swift reply. This has been changed with bug 1002597.

Philipp, will you have a look at this?
Flags: needinfo?(philipp)
Your welcome.

Doesn't work with Categories either. I have to Quit Thunderbird to dismiss the Choose a Color dialog window.
I can confirm under Linux Mint. Opening the system color chooser blocks TB and the chooser. I have to kill TB.
Status: UNCONFIRMED → NEW
Ever confirmed: true
My Linux machine isn't easy to boot thanks to a bluetooth keyboard and no grub support for a bluetooth stack. I'll see if I can get to this some time this week. If someone else wants to take over please do.
Blocks: ltn40
Could you test if the HTML5 color picker works in Firefox 38 on Linux, e.g. be testing the demo on <http://www.wufoo.com/html5/types/6-color.html>? This information might be useful to decide if this is problem in Core/Toolkit or Thunderbird/Lightning.
(In reply to Stefan Sitter from comment #10)
> Could you test if the HTML5 color picker works in Firefox 38 on Linux, e.g.
> be testing the demo on <http://www.wufoo.com/html5/types/6-color.html>? This
> information might be useful to decide if this is problem in Core/Toolkit or
> Thunderbird/Lightning.

Everything on the demo works for me using 64-bit Firefox 38.0b4 on Linux.
So what should we do? Back-out the html color picker patch and revert to the old but working xul color picker? Or accept the fact that the color selection feature is broken for users running Linux?
If this cannot be fixed in time, we should consider to back this out from beta. Based on the reports, it's not just broken but requires TB to be killed.
Thunderbird only needs to be killed if you are creating a new Category. Wouldn't fixing it for creating a New Calendar fix both problems?

If not I'm for reverting to the old but working xul color picker.
Attached patch Modal dialog workaround (obsolete) β€” β€” Splinter Review
This seems to be triggered by opening the color picker from a modal dialog. Opening the dialogs as modeless would be one workaround.
Attachment #8596864 - Flags: feedback?(philipp)
I suspsected this might be a workaround. We should file a core bug for this, although I doubt it will be fixed in the 4.0 timeframe. If this happens only on Linux, I think we should use this workaround only for Linux. Making these dialogs non-modal can be quite messy when switching windows.
Flags: needinfo?(philipp)
Comment on attachment 8596864 [details] [diff] [review]
Modal dialog workaround

r+ if made Linux-only with a comment to this bug. I'd like to get some feedback from Paenglab on the UX here too.
Attachment #8596864 - Flags: feedback?(richard.marti)
Attachment #8596864 - Flags: feedback?(philipp)
Attachment #8596864 - Flags: feedback+
Looks like the problem with Lightning was already observed some time ago and filed as Core Bug 1139315 but no information was send to the Lightning community.
Comment on attachment 8596864 [details] [diff] [review]
Modal dialog workaround

f+ also for Linux only. I tested it on Linux and Windows. On Windows the dialog could jump behind TB and then everything works but a new try to open the properties fails for the user (not really, but the dialog doesn't jump in front). On Linux interestingly the dialog and the color picker are staying always in front of TB.
Attachment #8596864 - Flags: feedback?(richard.marti) → feedback+
Assignee: nobody → matthew.mecca
Depends on: 1139315
Opens dialogs as modeless in linux only.

Could someone also confirm this works as expected on mac / windows?
Attachment #8597661 - Flags: ui-review?(richard.marti)
Attachment #8597661 - Flags: review?(philipp)
Attachment #8597661 - Flags: approval-calendar-beta?(philipp)
Attachment #8597661 - Flags: approval-calendar-aurora?(philipp)
Status: NEW → ASSIGNED
Comment on attachment 8597661 [details] [diff] [review]
Workaround v2 - linux only

Not really a ui-r, so f+

Tested on Win7 and Linux Mint.
Attachment #8597661 - Flags: ui-review?(richard.marti) → feedback+
Attachment #8597661 - Flags: review?(philipp)
Attachment #8597661 - Flags: review+
Attachment #8597661 - Flags: approval-calendar-beta?(philipp)
Attachment #8597661 - Flags: approval-calendar-beta+
Attachment #8597661 - Flags: approval-calendar-aurora?(philipp)
Attachment #8597661 - Flags: approval-calendar-aurora+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Keywords: checkin-needed
Whiteboard: [checkin-needed comm-aurora, comm-beta]
Target Milestone: 4.0 → 4.2
Philipp, could you include this in the next 4.0 Beta build?
Flags: needinfo?(philipp)
Sure, sorry this went by unnoticed.
Flags: needinfo?(philipp)
Whiteboard: [checkin-needed comm-aurora, comm-beta]
If you want to test (and hopefully verify) the fix before Lightning 4.0b5 is officially available on addons.mozilla.org please try a test build from https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/candidates/4.0b5-candidates/build1/
I've been using it, and can verify the fix works for me when creating a new calendar or category.
You need to log in before you can comment on or make changes to this bug.