The default bug view has changed. See this FAQ.

Attendees Dialog: Zoom buttons don't work

VERIFIED FIXED in 1.0b1

Status

Calendar
Dialogs
VERIFIED FIXED
10 years ago
6 years ago

People

(Reporter: Andreas Treumann, Assigned: Decathlon)

Tracking

Lightning 0.7
1.0b1

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

10 years ago
REPRODUCTION:
=============

- open the Attendees Dialog
- push the Zoom Buttons

RESULT:
=======

- nothing happens

EXPECTED RESULT:
================

- pushing the Zoom Buttons changes the zoom of the time scale 

REPRODUCIBLE:
=============

- always

Comment 1

10 years ago
Thunderbird v2.0.0.6 (20070728) / Lightning v0.7pre (2007081804)

This error has still not fixed in the above listed version. The ± zoom buttons doesn't work at all although the pulldown menu works properly.

Comment 2

10 years ago
(In reply to comment #1)
This is the reason why the bug is still in Status: NEW instead of FIXED. <https://bugzilla.mozilla.org/page.cgi?id=fields.html#status>
Assignee: michael.buettner → nobody
Component: Lightning Only → Theme
Product: Calendar → Firefox
Target Milestone: --- → Firefox 3
Version: Lightning 0.3 → Trunk
Oh, crap, sorry, moving back, send hatemail to this address.
Component: Theme → Lightning Only
Product: Firefox → Calendar
Target Milestone: Firefox 3 → ---
Version: Trunk → Lightning 0.7
I can confirm also on 0.9 release on Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.17) Gecko/20080914 Lightning/0.9 Thunderbird/2.0.0.17 ID:2008091421
Summary: [Proto] Attendees Dialog -> Zoom Buttons doesn't work → Attendees Dialog: Zoom buttons don't work
Dialog is also present in Sunbird -> Move to Calendar:General
Component: Lightning Only → General
QA Contact: lightning → general

Comment 6

8 years ago
It is already unsolved: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091002 Lightning/1.0pre Shredder/3.0pre
(Assignee)

Comment 7

8 years ago
Created attachment 404449 [details] [diff] [review]
patch_v1

What about this proposal?
Assignee: nobody → bv1578
Attachment #404449 - Flags: review?(philipp)
Status: NEW → ASSIGNED
Component: General → Dialogs
QA Contact: general → dialogs

Comment 8

8 years ago
It is going to be applied to Lightning nightly builds? It is to embarrassing for me to compile TB+Lightning.

Tested on latest Lightning nightly build and it is still unsolved.
Attachment #404449 - Flags: review?(philipp) → review+
Comment on attachment 404449 [details] [diff] [review]
patch_v1

Looks good codewise, although at least under linux the toolbar doesn't look like it is supposed to (screenshot follows).

If you just directly put the toolbarbuttons/menulist into the hbox, everything looks fine on linux. If this also works fine under windows, could you attach a patch ready for checkin?
Created attachment 405660 [details]
Screenshot - Linux
(Assignee)

Comment 11

8 years ago
Created attachment 405671 [details] [diff] [review]
patch_v2

I added that 'hbox' only to prevent the same flaw I see on your screenshot with Linux. If I delete the box, I get on Windows the same identical error you get with the box.

I tried to put the toolbar just after the main 'hbox' element with every other element inside the toolbar (without added hbox), in this way it looks fine on Windows, how does it look on Linux?
Attachment #404449 - Attachment is obsolete: true
Attachment #405671 - Flags: review?(philipp)
Created attachment 405715 [details]
Screenshot - Linux - v2

The hbox itself is fine, but you mean with the <hbox> and without the <toolbar> there is the strange border?

I'd suggest to revert to only use a <hbox> containing the toolbar elements and then use the DOM inspector to find out what is causing the strange border.

On linux and with the <toolbar> element, I found that -moz-appearance: toolbar is causing the small border, which is unfortunate. Of course adding -moz-appearance: none fixes this, but this makes the <toolbar> function mostly like a normal <box>.
Attachment #405660 - Attachment is obsolete: true
(Assignee)

Comment 13

8 years ago
Created attachment 405752 [details] [diff] [review]
patch_v3

(In reply to comment #12)
> 
> The hbox itself is fine, but you mean with the <hbox> and without the 
> <toolbar> there is the strange border?
>

You are right, the <toolbar> element is superfluous. It works fine without it, no extra borders if I delete it.
I attach this patch which merely replaces the static images of the buttons with two toolbarbuttons.
If you think it needs an extra hbox which includes the toolbarbuttons and dropdown menulist, you can add it before the check-in because I've just tried on Windows and it works fine with a such hbox too.
Attachment #405671 - Attachment is obsolete: true
Attachment #405752 - Flags: review?(philipp)
Attachment #405671 - Flags: review?(philipp)
Comment on attachment 405752 [details] [diff] [review]
patch_v3

Looks good, I'll keep it as is. r=philipp
Attachment #405752 - Flags: review?(philipp) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/024643dc0f01>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0

Updated

7 years ago
Status: RESOLVED → VERIFIED
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.