Column width mistake in Application prefpane's columns header and data list

NEW
Unassigned

Status

()

--
trivial
11 years ago
9 years ago

People

(Reporter: masa141421356, Unassigned)

Tracking

(Depends on: 1 bug, {polish})

Trunk
x86
Windows XP
polish
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [polish-hard] [polish-visual][polish-p3])

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040805 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040805 Minefield/3.0pre

At Option > Application prefpane,
Column width of column header and data list is not same.


Reproducible: Always

Steps to Reproduce:
1.Show Application prefpane,
2.
3.
Actual Results:  
Column width of column header and data list is not same.


Expected Results:  
Column width of column header and data list should be same.
(Reporter)

Comment 1

11 years ago
Created attachment 314562 [details]
Screenshot
(Reporter)

Updated

11 years ago
Version: unspecified → Trunk
Summary: Column width mistach in Application prefpane's columns header and data list → Column width mistake in Application prefpane's columns header and data list
(Reporter)

Comment 2

11 years ago
It seems to be:
 Width of column header = listWidth * 0.5
 Width of data list = (listWidth - scrollbarWidth) * 0.5
This happens because we're not using real columns in the list, we're faking them with equalsize="always" on both the header and the rows, and the rows become narrower than the header when the scrollbar appears.

I don't know of a simple fix for this.  Bug 367843 would probably have done it, but enn wasn't sure he wanted it, and it's probably a bigger change than we can take at this point.  Maybe there's some applications prefpane-specific hack that'll work, though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 367843
Keywords: polish
Whiteboard: [polish-hard] [polish-visual]
This bug's priority relative to the set of other polish bugs is:
P3 - Polish issue that is in a secondary interface, occasionally encountered, or is not easily identifiable.

Setting to P3 since I wasn't able to notice this problem without someone else pointing it out and I actually worked on the mockups for the UI.  Very soundly in a secondary interface though.
Whiteboard: [polish-hard] [polish-visual] → [polish-hard] [polish-visual][polish-p3]
You need to log in before you can comment on or make changes to this bug.