The default bug view has changed. See this FAQ.

full page zoom interacts poorly with image auto zoom

RESOLVED FIXED

Status

()

Core
DOM
P2
normal
RESOLVED FIXED
10 years ago
11 months ago

People

(Reporter: ted, Assigned: smaug)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Using full page zoom when viewing an image seems to confuse image auto zoom.  It seems like the canvas is expanding in size, but the auto-zoom code keeps trying to shrink the whole thing to fit.

Comment 1

10 years ago
(In reply to comment #0)
> Using full page zoom when viewing an image seems to confuse image auto zoom. 
> It seems like the canvas is expanding in size, but the auto-zoom code keeps
> trying to shrink the whole thing to fit.

Yeah, that seems like a good description of the problem; the issue is that the image auto zoom code doesn't know what's going on.  I guess the image document code could query for the current zoom level and adjust as appropriate.

I'm not completely sure how exactly it should adjust, though; there doesn't seem to be an intuitive way to deal with the interaction between the scaling and the zoom/restore feature.

Updated

10 years ago
Keywords: uiwanted

Updated

10 years ago
Duplicate of this bug: 397618

Updated

10 years ago
Version: unspecified → Trunk
Flags: blocking1.9?
Can we make the image document understand full page zoom, and have it modify full page zoom to do the actual zoom?  That is, it should set the full page zoom to 1.0 or 0.x or whatever to zoom higher or lower; if the user then uses control-+/- to zoom, they'll just be modifying the same zoom variable.  Clicking the image will reset it to either shrink-to-fit or to 1:1.  How's that sound?

Comment 4

9 years ago
+ing since this is new with the fp zoom.  
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2

Updated

9 years ago
Duplicate of this bug: 415445

Updated

9 years ago
Duplicate of this bug: 409169
Created attachment 301505 [details] [diff] [review]
possible patch

I think this is the behavior I'd like to have.
+/- or clicking has the same effect as now, but scaled using zoom-in/-out level.
If there is some zooming used, resizing window doesn't affect to image size.
Comments?
(In reply to comment #1)
> I'm not completely sure how exactly it should adjust, though; there doesn't
> seem to be an intuitive way to deal with the interaction between the scaling
> and the zoom/restore feature.
I agree with Eli, zoom/restore/resize and page scaling don't fit together
very well, but I do see use cases for them both.

->DOM, since this is implemented in ImageDocument
Component: GFX → DOM
QA Contact: general → general
Created attachment 301556 [details] [diff] [review]
v2

This has behavior closer to what vlad described.
page-scale zooms in/out, mouseclick or +/- keypress restores the old style
shrink-to-fit/1:1.

Not sure who should review this, but since jst reviewed Bug 73322 (only 5 years ago ;) )...
Assignee: nobody → Olli.Pettay
Status: NEW → ASSIGNED
Attachment #301556 - Flags: superreview?(jst)
Attachment #301556 - Flags: review?(jst)
Comment on attachment 301556 [details] [diff] [review]
v2

Or maybe still not good enough
Attachment #301556 - Flags: superreview?(jst)
Attachment #301556 - Flags: review?(jst)
Comment on attachment 301556 [details] [diff] [review]
v2

Bah, defining how this should work with resize-shrink-to-fit is hard, so perhaps the patch is enough, at least for now.
Attachment #301556 - Flags: superreview?(jst)
Attachment #301556 - Flags: review?(jst)

Comment 13

9 years ago
How will this behave when a global page zoom value is set (see bug 414636)?

This is probably not terribly important, since there is no UI in Firefox to set the global zoom (at least for now), but I'm just curious.
Have to test, but I guess I could test if there is global zoom value
and use that instead of 1.0

And if someone has good suggestion how this should work, comments welcome.
Comment 3 doesn't take account resize-shrink-to-fit behavior.
If I read the code right, the global zoom level uses 
nsIContentPrefService which is under toolkit/.
I *really* don't want to make content/ depend on toolkit/.
Not all gecko apps are toolkit apps.
So unless that pref is changed to be set as a normal pref, there isn't much
ImageDocument can do.

And anyway, I think this feature doesn't even need to care about global 
zoom: either use 1:1/shrink-to-fit or whatever page zoom level there is.
Doesn't matter if page zoom level is set based on global zoom.
Comment on attachment 301556 [details] [diff] [review]
v2

There's already been talk about moving the interface nsIContentPrefService into content so that we could use it from there, so if there's a need to do that now or later, we should just do that (but leave the implementation where it is and use the interface conditionally).

Either way, this seems like a step in the right direction, so r+sr=jst
Attachment #301556 - Flags: superreview?(jst)
Attachment #301556 - Flags: superreview+
Attachment #301556 - Flags: review?(jst)
Attachment #301556 - Flags: review+
I dared to add SetZoomLevel(1.0) still to toggleImageSize (only for SM) and
also to OnStartContainer to make initial imagesize reasonable when zooming and overflowing.
It is not clear what user expects in different cases, so trying something, which
at least works comparing to current broken behavior :(
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Depends on: 457291
Depends on: 466315
Blocks: 467679

Updated

8 years ago
Keywords: uiwanted
Depends on: 489091
Depends on: 503729
You need to log in before you can comment on or make changes to this bug.