Closed
Bug 195854
Opened 21 years ago
Closed 20 years ago
Browser expands larger then screen size
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: cloveious, Assigned: asa)
References
()
Details
User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.4a) Gecko/20030228 Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.4a) Gecko/20030228 In the past couple weeks i have noticed webpages here and there that expand larger then my current screen size, The above link is a sample of one of those, I find this bug extreamly anoying simply because it usually happens unexpectedly and its difficult to the browser down to a decent size when it happenes. Reproducible: Always Steps to Reproduce: 1. Click on above link 2. 3. Actual Results: Browser expands beyond my 1024 x 768 screen size Expected Results: Browser should stay the same size or a size within reason
Reporter | ||
Comment 1•21 years ago
|
||
Sorry I forgot to add I clicked the link off http://www.gameboyadvance.com/downloads.jsp, It only happens when a link is opened in a new window.
Reporter | ||
Comment 2•21 years ago
|
||
I think its the way the link is #<a href="wp_smw_1024.jsp" onclick="openCenteredWindow(this.href, 'wallpaper', 1024, 768, 0, 0, 0); return false;"><img src="images/btn_arrow_d_ff6600.gif" width="7" height="7" alt="" border="0" hspace="2" />1024x768</a><br /># Perhaps there is a better way for Mozilla to handle how it opens a specific resolution.
Comment 3•21 years ago
|
||
I also met such situations. There are 2 problems here: 1) Border size isn't counted yet (and reported) for BeZilla. Maybe due to some unimplemented method in nsWindow. 2)Title bar don't belong to BWindow thus also is aout of counting. Simplest trick to avoid some problems is filling stub implementation of NS_METHOD nsWindow::ConstrainPosition(). E.g., simplicistic example here: NS_METHOD nsWindow::ConstrainPosition(PRBool aAllowSlop, PRInt32 *aX, PRInt32 *aY) { if (eWindowType_dialog != mWindowType && eWindowType_toplevel != mWindowType) return NS_OK; *aX=2; *aY=28; return NS_OK; } So window cannot be postitioned on Create in way where Title bar is outside screen. This should allow to drag window in some resizable position. But current trick os opening in another workspace Worksapces application and move BeZilla using this app.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is this really a bug, or, does the offending page actually try to resize the window larger than the screen, so you can't move/resize it? Plus, I think there is code in the "big" widget patch, that may fix this? Sergei, thoughts?
Comment 5•21 years ago
|
||
as far as i remember, implementation of ConstrainPosition was submitted by Paul, wondering if it was checked in tree. Usually i have some things disabled in Advanced->Script&Plugins, like changing existing window size or raise/lower - against moron web-designers. But for test purpose i enabled those and couldn't reproduce bug with my version of libwidget.
Comment 6•20 years ago
|
||
cannot reproduce anymore. NS_METHOD nsWindow::ConstrainPosition() was checked in long ago.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 7•20 years ago
|
||
Sergei, thanks for closing this, I don't have a x86 computer running BeOS anymore, Since my BeOS computer died. and had no way to test this,
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•