Closed
Bug 449781
Opened 17 years ago
Closed 17 years ago
Dragging a zoomed tab applies zoom to chrome
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
FIXED
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
Details
Attachments
(1 file)
|
11.14 KB,
patch
|
roc
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
STEPS TO REPRODUCE:
1) Load a page in a tab
2) Zoom in a few times
3) Drag the tab to a different window
ACTUAL RESULTS: Chrome in the different window gets the zoom applied
EXPECTED RESULTS: don't mess with me chrome, I tells you!
Many thanks to c.levin@gmail.com for spotting this.
| Assignee | ||
Comment 1•17 years ago
|
||
Oh, this is fun. Apparently it's been broken all along, actually, for cases when a subdocument went display:none then back to visible. We just never ran into it much, because apparently we don't run into too much trouble if multiple content frames share the same device context?
That's what's going on here: the content document ends up with the chrome device context, because unlike DocumentViewerImpl::Init (which gets the device context passed in), DocumentViewerImpl::Show just grabs the device context off the parent widget... which is SO the wrong thing to do.
| Assignee | ||
Comment 2•17 years ago
|
||
roc, any idea how to test this? Basically we're screwing up the pixel scale on our parent frame's device context....
If DrawWindow uses the same device context as normal painting, it would be pretty easy to write a reftest for this using enablePrivilege, I guess. Have a child which is hidden-visibility, set it to display:none, then display:whatever, then zoom the child and compare to our initial state, or something. Would that work?
Attachment #332970 -
Flags: superreview?
Attachment #332970 -
Flags: review?(roc)
| Assignee | ||
Updated•17 years ago
|
Attachment #332970 -
Flags: superreview? → superreview?(jst)
Updated•17 years ago
|
OS: Mac OS X → All
Hardware: PC → All
Version: unspecified → Trunk
I think that would work.
Comment 5•17 years ago
|
||
Will bug 408496 be fixed, or is it maybe related?
| Assignee | ||
Comment 6•17 years ago
|
||
Maybe. Hard to say from that bug.
Attachment #332970 -
Flags: review?(roc) → review+
Updated•17 years ago
|
Attachment #332970 -
Flags: superreview?(jst) → superreview+
| Assignee | ||
Comment 7•17 years ago
|
||
Pushed this, with a mochitest. I added a little mochitest helper file for doing reftest-like stuff.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Comment 8•17 years ago
|
||
Changeset id (to see the mochitest):
http://hg.mozilla.org/index.cgi/mozilla-central/rev/1ecbdcb04b8e
You need to log in
before you can comment on or make changes to this bug.
Description
•