173805 - Text Zoom in message pane discarded when same message opened in new window

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Roger M. Wilcox]

Steps to reproduce:
===================

1.  Launch Netscape 7.0 mail.
2.  Set View->Text Zoom to 50%.
3.  Double-click on a message header in the right-hand pane to view it in a 
separate window.

Expected result: The newly-opened window should display the message with a text 
zoom of 50%.

Actual result: The newly-opened window displays the message with a text zoom of 
100%.




This may be related to a problem we're having in an app we're developing, which 
uses an embedded Gecko viewer.  We can't get an nsIMarkupDocumentViewer from 
the Gecko viewer (and thus can't call SetTextZoom()) until the Gecko viewer has 
finished its first Navigate() operation.

Comment 1

[Dave Barrowman]

Marking topembed to get on the EDT radar.

Comment 2

[Juan José Mata]

Discussed at EDT: plussing topembed nomination.

Comment 3

[Kathleen :Brade]

confirming bug; not sure who this belongs to
it probably should be reassigned?

Comment 4

[Juan José Mata]

It is probably with the right owner right now if we believe it to be an
app-level problem.  We need to figure out a way for the XUL front-end to be able
to do this without having to hack their way around potential Gecko API problems
(like loading about:blank first then changing the zoom level which you mentioned
elsewhere, Kathy ...)

If Gecko should be doing something special to track zoom levels across windows
based on opening history (Gecko windows opened by another Gecko window
displaying at 50% zoom level should remain at 50% zoom level) then I can see it
changing hands over to somebody over at layout.  This could be tricky and
undesireable however since the chrome might also get rendered at a different
zoom level than expected, so app-level seems like the right place to fix this.

All we would need to figure out is which API should be called to make it happen
for the app, without any "load about:blank" hacks.

Am I making any sense or talking out of *ss here?

Comment 5

[Juan José Mata]

Some of the latter.  Ignore the silly concerns about chrome being rendered under
the magnification level of the parent window.

Comment 6

[Juan José Mata]

Minusing topembed nomination, the embedding client application does not exhibit
the problem similar to the one reported here in their app.

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420