if an image is smaller than the space available for its thumbnail it shouldn't be stretched

RESOLVED WONTFIX

Status

()

Firefox
Tabbed Browser
--
trivial
RESOLVED WONTFIX
13 years ago
5 years ago

People

(Reporter: Felipe Corrêa da Silva Sanches, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [cst: request reviews after mac user tests patch], URL)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+

if an image is smaller than the space available for its thumbnail on a tab it
shouldn't be resized because it changes its aspect ratio. 

example: http://newsimg.bbc.co.uk/nol/shared/img/v3/print.gif

Reproducible: Always

Steps to Reproduce:



Expected Results:  
when image is small enough, its thumbnail should be the image in real size.
sound like a fair request
cc CTho
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is the bug that the image should not be resized, that the image's aspect ratio
shouldn't be changed. I prefer the latter since it would apply to any sized
images, not just very small ones, but then I would bet that the former is easier
to implement.
You can get it to always enforce the aspect ratio by changing width and height
to max-width and max-height here:
http://lxr.mozilla.org/seamonkey/source/toolkit/themes/winstripe/global/browser.css#26

I'm not entirely sure if this is adequate, as it means small images wouldn't get
scaled up.
OS: Windows 2000 → All
(Reporter)

Comment 4

13 years ago
(In reply to comment #3)
> I'm not entirely sure if this is adequate, as it means small images wouldn't get
> scaled up.

That´s it! Small enough images shouldn´t be scaled up. These small images are
probably designed to be seen this way. Why would we scale them up if they
(suposedely) are good-looking at their original (small) size ? Scaling up would
just distort them.

I mean, in pseudo-code: 

if (image.xsize>MAX_TAB_ICON_XSIZE or image.ysize>MAX_TAB_ICON_YSIZE)
   use_tabicon(scale_down(image)); // scale it down to fit our 
                                   //MAX_TAB_ICON_XSIZExMAX_TAB_ICON_YSIZE
                                   //(16x16) tabicon available space.
else
   use_tabicon(image);  //don´t scale it up. 
                        //Use the original image.
Created attachment 189571 [details] [diff] [review]
seamonkey patch

I couldn't find a unix .tab-icon so I'm not sure what's going on for *nix.
Attachment #189571 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #189571 - Flags: review?(neil.parkwaycc.co.uk)

Comment 6

13 years ago
Hmm... if you have a single tab with only a small image loaded then the tab's
height is wrong (the width has an issue too but it's not so bad).

(In reply to comment #5)
>I couldn't find a unix .tab-icon so I'm not sure what's going on for *nix.
Most of the unix classic styles are the same as Windows.
Summary: if an image is smaller than the space available for its thumbnail it shouldn't change aspect ratio → if an image is smaller than the space available for its thumbnail it shouldn't be stretched
Attachment #189571 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #189571 - Flags: review?(neil.parkwaycc.co.uk)
(In reply to comment #6)
> Hmm... if you have a single tab with only a small image loaded then the tab's
> height is wrong (the width has an issue too but it's not so bad).

Based on my understanding of XUL and the effects of the relevant CSS properties,
I think we have to add an extra box around the icon with min-width and
min-height to ensure that a smaller image doesn't result in a smaller tab.  Is
that correct?
Created attachment 196377 [details] [diff] [review]
seamonkey patch, v2

This one works properly on Windows.  Untested on mac, linux.  Large images
still get forced to 16x16.
Attachment #189571 - Attachment is obsolete: true
Attachment #196377 - Flags: superreview?
Attachment #196377 - Flags: review?
Comment on attachment 196377 [details] [diff] [review]
seamonkey patch, v2

Maybe I should set the flags right ;)
Attachment #196377 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #196377 - Flags: superreview?
Attachment #196377 - Flags: review?(db48x)
Attachment #196377 - Flags: review?

Comment 10

13 years ago
Comment on attachment 196377 [details] [diff] [review]
seamonkey patch, v2

You need to patch themes/modern/global/browser.css and
themes/classic/global/mac/globalBindings.xml (maybe ask stefan to test?) and I
would prefer the .tab-container rule to be before the .tab-icon rule.
Attachment #196377 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview-
Created attachment 197437 [details] [diff] [review]
SeaMonkey patch, v3

Needs testing on Mac.
Attachment #196377 - Attachment is obsolete: true
Whiteboard: [cst: request reviews after mac user tests patch]

Comment 12

13 years ago
The patch works fine on mac, except for one issue: In Classic skin, text/icons
in tabs are not vertically centered anymore. I'll attach a screenshot.

Comment 13

13 years ago
Created attachment 199425 [details]
Screenshots showing the issue (lower one with patch applied)

Comment 14

13 years ago
Hmm, this seems to be a hard one. It appears that the "max-height: 16px" etc
makes both the tab-icon and tab-text loose it's vertical position (see
screenshot). Don't ask me why, but it must have something to do with the native
theming... One way of fixing this is to push everything down 3px by increasing
the top-margin of .tab-icon to 4px total and adding ".tab-text { padding-top:
3px; }" (both in global/mac/browser.css).

Note that there's no need to patch global/mac/globalBindings.xml here. The tab
height/width is always ok without changes in globalbindings.xml.

Now, pushing down icons and text works fine as long as you keep the tabs
native-styled. However, if you for insatnce look at the result with "* {
-moz-appearance: none; }" in your userChrome.css it's all messed up. Now icon
and label text gets pushed down from it's previously correct position (before
pushing down stuff) and extends below the bottom of the tab.

Comment 15

13 years ago
> Hmm, this seems to be a hard one.

No, it isn't. Just modify attachment 197437 [details] [diff] [review] (v3) to include this into themes/classic/global/mac/browser.css:

.tabbrowser-tab {
  -moz-box-align: center;
}

Comment 16

13 years ago
Created attachment 207092 [details]
Screenshots showing effect of changes in mac classic's browser.css

(In reply to comment #15)
> > Hmm, this seems to be a hard one.
> 
> No, it isn't. Just modify attachment 197437 [details] [diff] [review] [edit] (v3) to include this into
> themes/classic/global/mac/browser.css:
> 
> .tabbrowser-tab {
>   -moz-box-align: center;
> }
>

Hmm... images are now a bit squeezed. Look at the mozilla-icon :/

Comment 17

13 years ago
Squeezed? No, they just now look like they should...

BTW: I tinkered with DOMI to find the cause for the need of the -moz-box-align rule on Mac - to no avail so far. A tab looks like this:
  <tab align=stretch vertical-align=baseline>
    <spacer height=25px>
    <hbox>     
    <spacer height=25px>
  </tab>
The hbox has (for me) usually a rendered height of 19px, regardless of CTho's patch being applied or not. But without that, the spacers have their set height of 25 and everything looks fine; with that patch, they take the height of the hbox, despite their set height and despite the stretch value...
If someone else is bored and has a Mac, maybe he can tell what's going on here - I can't...

After all, I think the -moz-box-align=center should probably be applied to all tabs, not just Mac Classic.

Comment 18

13 years ago
(In reply to comment #17)
> Squeezed? No, they just now look like they should...

Take a look at the mozilla-icon, for instance. It's 16x16 px... So is the mozdev icon.

Comment 19

13 years ago
> > Squeezed? No, they just now look like they should...
> 
> Take a look at the mozilla-icon, for instance. It's 16x16 px... So is the
> mozdev icon.

Ah, sorry, you're right. And this squeeze is because the <image> still gets the margin style rules for .tab-icon, even though it can't grow that amount, the parent element has a fixed size. All the former image styles should probably be redirected to this container...
stefanh, mnyromyr, can either of you suggest fixed CSS?

Updated

10 years ago
Assignee: stefanh → nobody
The standard aspect ratio for favicons is 1:1. Showing favicons at a different aspect ratio hurts the consistency across tabs. A different approach would be to use a generic image favicon for these tabs, but this also removes the ability for users to quickly distinguish between multiple images opened in separate tabs.

If users still want this feature, it can be easily achieved via an addon.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.