Closed Bug 342679 Opened 18 years ago Closed 17 years ago

Tab drag-drop indicator arrow almost hidden when at extreme left

Categories

(Firefox :: Tabbed Browser, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: waynegwoods, Unassigned)

References

Details

(Keywords: polish)

Attachments

(1 file, 2 obsolete files)

Surprised I can't find a bug for this already, since I think it's existed as long as tab dragging has...

When at the left-most possible position (to the left of the first tab), the tab drag-and-drop indicator arrow is all but entirely missing, due to it being positioned outside the window.

1. Open a browser window with two tabs.
2. Drag the second one over the top of the first.
3. Observe that the drop indicator arrow is 100% visible when positioned to the right of the first tab, but almost gone when positioned to the left

This doesn't seem to be such an issue at the extreme right of the tab bar, as the right-most tab (even when backgrounded) is created with a border between it and the end of the tab bar (i.e. there's enough tab bar background "buffer" to accommodate the drawing of the right half of the indicator).

The first/extreme left tab, however, seems to be created with a border that reaches all the way to the edge of the tab bar (even though the image of the tab when it's foregrounded suggests one), and that seems to be the problem. Maybe a more restrictive border could be set?

Another symptom of the border problem is that the tab focus ring for the first tab (when active/foregrounded) stretches all the way off the edge of the window, rather than being a close fit like other tabs.
I looked at that, and I don't think so. I admit I don't 100% understand the situation there, but I think it's to do with the arrow being drawn in the wrong place with respect to the tab image at the far right.

While I think in this bug, the arrow is technically being drawn in the correct place with respect to the tab. But because of the extreme left border on the first tab, it ends up completely hidden. I could be wrong, though.
for this bug, beltzner was suggesting in another bug that what he wants is for the arrow to be drawn at a 45 degree angle in this scenario, and in the scenario when the arrow is at the other side.
Assignee: nobody → sspitzer
Ah yeah, I saw that. That solution wouldn't stop the focus outline (and maybe other things) from overflowing the window, but the arrow is the main thing. Does the focus outline serve any purpose anyway?
*** Bug 348139 has been marked as a duplicate of this bug. ***
Of note, I initially thought that the first tab (when backgrounded) was artificially longer to make it extend all the way to the window edge. The reason being that when it was foregrounded, the tab shrank away from the edge. I now see that that's not the case. When foregrounded, the first tab actually distorts to appear shorter than normal, due to:
  tab[first-tab="true"] > .tab-image-left {
    margin-left: 3px !important;
  }

I can only assume that code was added with the intention of creating a border between the tab and the window edge, but it didn't work right. At least, I can't see any other reason for having it. Maybe there's a better way of doing the same thing.
The following code works much nicer:

  .tabs-left {
    display: -moz-box !important;
    width: 5px !important;
  }

It allows 5px before the first tab, which is just enough space for the indicator to fit. Only problem is that the 5px space remains when the tab scroll arrows appear, and it's redundant at that point. I don't know if there's an easy way of checking if the scroll arrow is (un)collapsed in the .tabs-left selector, since they're not in a direct hierarchy.
Actually, there is an easy way of switching it on and off:

  .tabbrowser-tabs:not([overflow="true"]) .tabs-left {
    display: -moz-box !important;
    width: 5px !important;
  }

However, when the indicator arrow is in the first position, it's being horizontally stretched. I can't seem to find a way to fix that in css alone.
(In reply to comment #8)
> However, when the indicator arrow is in the first position, it's being
> horizontally stretched. I can't seem to find a way to fix that in css alone.

... or I could be a dope who didn't realize that the far left of his old crt monitor was distorting images. The css isn't stretching the indicator at all. The code works perfectly. Suggested patch to follow, as soon I can can check out any potential bidi issues.

Even if you want to go with the angular drag indicator in the future (comment 3), this is a low-impact css fix for now. It simply:
(1) Sets tabs-left to a width of 5px if the tab strip isn't in overflow. Just enough for the indicator to fit in
(2) Removes the weird 3px margin-left placed on the first tab

I've tested on Fx 2 and hopefully it could slip in with the other theme polishes that are still going on.
Attachment #235547 - Flags: superreview?(mconnor)
Attachment #235547 - Flags: review?(sspitzer)
I doubt it should really block Fx 2, but I'm hoping the request will at least get it noticed for consideration. This is a very low-impact patch that would remove an obvious UI irregularity in Firefox 2.
Flags: blocking-firefox2?
Flags: blocking-firefox2? → blocking-firefox2-
Keywords: polish
Seth, now that Fx 2.0 is in rc phase, do you think you could please take a look at this for the trunk? I think that the Windows theme has already been modified along exactly the same lines... unfortunately it's too late for the Mac 1.8... unless it can be checked in for a post Fx 2.0 revision.
> Seth, now that Fx 2.0 is in rc phase, do you think you could please take a look
> at this for the trunk? 

sorry for the delay wayne.  I'll take a look today.
Thanks Seth! Sorry, however... Since Cocoa was enabled, I just realized that it's not going to be testable on the trunk until bug 332913 (Cocoa drag & drop) is fixed. The patch for that should be in very soon.

Updating this patch because of bit rot, anyway.
Attachment #235547 - Attachment is obsolete: true
Attachment #241381 - Flags: superreview?(mconnor)
Attachment #241381 - Flags: review?(sspitzer)
Attachment #235547 - Flags: superreview?(mconnor)
Attachment #235547 - Flags: review?(sspitzer)
Tab dnd is back, so this can now be tested properly in review (when you've recovered from your Firefox 2 hangovers, anyway ;) ) Thanks!

If you decide you don't like the 5px space to the left, the patch can still be applied with a narrower tabs-left. The current tab-image-left margin for the first tab is 3px. So replacing it with a 3px-wide tabs-left would give the same outward appearance, except that the layout of the first tab would no longer be distorted, and the dnd indicator wouldn't be pushed so far to the left (though if the width is 3px instead of 5, a part of it would still be hidden).
Attachment #241381 - Attachment is obsolete: true
Attachment #243610 - Flags: superreview?(mconnor)
Attachment #243610 - Flags: review?(sspitzer)
Attachment #241381 - Flags: superreview?(mconnor)
Attachment #241381 - Flags: review?(sspitzer)
Comment on attachment 243610 [details] [diff] [review]
Version 3 patch - updated for very minor bit-rot

I'm pretty sure this is the tail wagging the dog.  I'd rather offset the arrow position a little than muck with the visuals on the tabstrip.
Attachment #243610 - Flags: superreview?(mconnor)
Attachment #243610 - Flags: superreview-
Attachment #243610 - Flags: review?(sspitzer)
Fair enough if you don't want a 5px gap at the start.

It's not really the focus of this bug, but even if it stays at the current 3px, wouldn't my approach make more sense than the current hack, which artificially shrinks the first tab by forcing a margin on it?
sorry for the bug spam, re-assigning bugs back to default owner if I'm not working actively on them.
Assignee: sspitzer → nobody
Fixed as part of bug 390979. The final approach was to add a 3 px tabs-left to replace the whacked 3 px margin on the first tab. This meant the arrow could be drawn right next to the tab instead of being forced out of the window. A couple of px of the arrow is still clipped, but it's perfectly viewable now.
Status: NEW → RESOLVED
Closed: 17 years ago
Depends on: 390979
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: