Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#16411 closed bug (fixed)

Sanity - "Save Image" menu text overlapping. Cannot select image format.

Reported by: vidrep Owned by: waddlesplash
Priority: normal Milestone:
Component: Applications/Tracker Version: R1/beta2
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

hrev54429 x86_64

When saving a scanned image, a dialog box opens up whereby the image format is to be selected. The text of the menu items are overlapping, and the image format drop down selection is inactive. Screenshot1.png attached. This was working properly, until recently.

Attachments (2)

screenshot1.png (404.2 KB ) - added by vidrep 4 years ago.
screenshot2.png (31.3 KB ) - added by vidrep 4 years ago.

Download all attachments as: .zip

Change History (10)

by vidrep, 4 years ago

Attachment: screenshot1.png added

comment:1 by X512, 4 years ago

Can be regression caused by hrev54402, see #16368.

Last edited 4 years ago by X512 (previous) (diff)

comment:2 by waddlesplash, 4 years ago

Component: ApplicationsApplications/Tracker
Owner: changed from nobody to waddlesplash
Status: newassigned

Yes, it's possible Sanity is looking for one of the views that is now named differently, and positioning its controls there -- probably the BScrollBar. I guess I need to do something differently here.

comment:3 by waddlesplash, 4 years ago

Resolution: fixed
Status: assignedclosed

Fixed in hrev54473.

comment:4 by vidrep, 4 years ago

This is what it looks like now (screenshot2.png) after updating to hrev54473

by vidrep, 4 years ago

Attachment: screenshot2.png added

comment:5 by waddlesplash, 4 years ago

Resolution: fixed
Status: closedreopened

Indeed, it looks like I mistested...

Not sure what a proper fix for this will be then. Changing Sanity may be better.

comment:6 by waddlesplash, 4 years ago

Resolution: fixed
Status: reopenedclosed

Sanity fixed upstream.

comment:7 by nielx, 4 years ago

Milestone: UnscheduledR1/beta3

Assign fix to milestone:R1/beta3, as it looks like this fix will be part of that release.

As we started with the previous beta, we would like to use the Milestone field for fixed tickets to log from which release the improvement will be out. Therefore it is very much appreciated to assign the milestone when closing a ticket as fixed.

comment:8 by nielx, 4 years ago

Milestone: R1/beta3

Reverting ticket update, it seems to be a fix to a regression added _after_ milestone:R1/beta2, so it would be incorrect to add this to the list of fixes in milestone:R1/beta3.

My apologies for the noise.

Note: See TracTickets for help on using tickets.