Closed Bug 1132950 Opened 5 years ago Closed 5 years ago

Sorting direction markers are staying when another column is sorted

Categories

(Firefox :: General, defect)

38 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 38
Tracking Status
firefox37 --- unaffected
firefox38 --- fixed

People

(Reporter: alice0775, Assigned: ntim)

References

Details

(Keywords: ux-mode-error)

Attachments

(2 files, 1 obsolete file)

Steps To Reproduce:
1. Open about:config
2. Click "Preference name" tree header to change sort direction
   --- Sorting direction marker appears on "Preference name" column as expected
3. Click another tree header(e.g. "Status") to change sort direction
   --- Sorting direction marker appears on "Status" column  as expected
       However, Sorting direction marker is still shown on "Preference name" column

Actual Results:
Sorting direction markers are staying when another column is sorted

Expected Results:
Sorting direction markers should only be shown on column header that sorted
Flags: needinfo?(richard.marti)
It's not a bug directly introduced by bug 1125636.

The bug comes from https://dxr.mozilla.org/mozilla-central/source/toolkit/themes/shared/in-content/common.inc.css#686

There are two solutions:
1. Change the CSS code to not show the arrow when the empty attribute "sortDirection" is set.
2. Check where the "sortDirection" is set in JS and not removed when a other column is the active sort column.

For 1. I could fix this, but I think 2. would be cleaner but I'm not a JS specialist.
Flags: needinfo?(richard.marti)
Assignee: nobody → ntim007
Status: NEW → ASSIGNED
OS: Windows 7 → All
Hardware: x86_64 → All
Attached patch Patch (obsolete) — Splinter Review
Attachment #8564319 - Flags: review?(jaws)
Comment on attachment 8564319 [details] [diff] [review]
Patch

Review of attachment 8564319 [details] [diff] [review]:
-----------------------------------------------------------------

Looks like we could do with just the config.js changes. Any reason that we need to make the changes for common.inc.css? Presence of an attribute in XUL-land is pretty common to mean that it should be enabled.
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #4)
> Comment on attachment 8564319 [details] [diff] [review]
> Patch
> 
> Review of attachment 8564319 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks like we could do with just the config.js changes. Any reason that we
> need to make the changes for common.inc.css? Presence of an attribute in
> XUL-land is pretty common to mean that it should be enabled.

I guess so, I just want to prevent this in the future.
Comment on attachment 8564319 [details] [diff] [review]
Patch

Review of attachment 8564319 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, not necessary though. Let's keep this change small and only do the config.js change.

Also, we shouldn't use :-moz-any() as the right-most selector: https://developer.mozilla.org/en-US/docs/Web/CSS/:any#Issues_with_performance_and_specificity

r=me for only the config.js changes.
Attachment #8564319 - Flags: review?(jaws) → review+
Removed the CSS changes.
Attachment #8564319 - Attachment is obsolete: true
Attachment #8564582 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/2c5db2a83e34
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 38
Mistakenly filed against Firefox 38 and should be instead 38 Branch. Sorry for the spam. dkl
Version: Firefox 38 → 38 Branch
QA Whiteboard: [good first verify]
You need to log in before you can comment on or make changes to this bug.