Closed Bug 297653 Opened 20 years ago Closed 19 years ago

site display pages when using mozilla via remote desktop

Categories

(Core :: XUL, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED EXPIRED

People

(Reporter: moz-bugzilla, Assigned: jag+mozilla)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

When remoting in to a firefox 1.04 install that was left running at maximum
resolution on my widescreen display (1920x1200), which is monitor one of two
(second monitor runs at 1600x1200), the firefox window continues to render at
1920 pixels wide with no horizontal scrollbar, even though my Firefox window may
only be 900 pixels wide. The window also fails to respond to resize events;
restoring the window and then dragging the window borders or clicking
minimize/maximize to resize do nothing.

I didn't leave Firefox maximized this morning, so I'm unable to attach a
screenshot, but will attempt to do so tonight.

Reproducible: Sometimes

Steps to Reproduce:
1. On a system with a wide aspect LCD as the primary display (1920x1200
resolution) and a CRT monitor (1600x1200) as the secondary, XP Pro, leave
firefox running and maximized on the LCD.
2. Use remote desktop to log into the system.
3. Resize the Firefox window.
4. Observe that the page, and any other pages loaded, and the UI elements
(location/search bar, menus, bookmarks, etc), continue to be sized for the
maximum window size.
Actual Results:  
The firefox window displayed, but controls on the right side of the window
(Search Bar in particular) were not visible, and the page was sized for a larger
display (too wide to view on screen), but no horizontal scroll bar was displayed.

Expected Results:  
The page and UI elements should be appropriately resized to match the window size.

This appears to be related to bug 202800, but not the same.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050613
Firefox/1.0.4

I just tested this on a coworkers machine, he's on 1.0.2.

I had him set it to 1280x960, then remoted in.  It resized to my 1024x768 screen
(I set RDC to use full screen) fine, and I was able to Window it and then
Maximize it fine.

Unless this was changed in a newer version, it seems to be fine.  He's upgrading
now and I should be able to test again later.
I just tested with 1.0.4 and can't reproduce.  Same screen differences.  Resized
from maximized, which worked.  I believe I'm reproducing right according to
reporters instructions.  Marking WFM.

Windows XP SP2 if that means anything at all.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
This has happened to me consistently since version 1.0 RC1. Like I said, I'll
duplicate it tonight and get a screenshot. I'd also point out that I'm using a
wide-aspect LCD and a regular CRT in a multi-monitor configuration (so my
effective desktop resolution is 3520x1200). I have no idea whether it's the wide
aspect or the multi-monitor setup. I've also been able to duplicate it across
three windows installs, several monitor drivers, and two machines. If I can't
get it to happen consistently tonight, I'll re-close, but I should be able to
post a screenshot with no trouble.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
This occurred after I followed the directions I filed in the original bug
report exactly.
As you can see, the Go button/search bar are stuck off the right side of the
frame, as well as google being rendered too far to the right with no scroll bar.
The rendering issue appears on any page I go to. This occurs when I leave
Firefox maximized on my 1920x1200 display, then remote in. I suspect it has more
to do with the dual desktop configuration. The issue *can* be resolved by
restarting Firefox entirely.
Oh, as a note, this does happen on a fresh install with no extensions/themes.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → EXPIRED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: