Closed Bug 160627 Opened 24 years ago Closed 2 years ago

windows (popups) opened via javascript appear too small (have scrollbars)

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: wade, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(1 file)

window sizing test case
5.90 KB, application/zip
Details
If a javascript opens a chimera window (with a specified size, say for an image) the resulting window appears too small. The scrollbar gets cut off about 30 pixels from the bottom and the image doesn't fit in the window like it should. Use the javascript call window.open with a specified width and height to see this bug in action.
Wade, what Chimera build date are you reporting this problem against? Please provide an example URL.
I'm currently using both .4 and a build that is slightly newer (a few days after the .4 milestone release). A good site to view this bug is: http://www.panic.com/audion/ There are many screenshots illustrating the features of Audion, these windows appear too small and the scrollbars in Chimera appear incorrectly. The windows should appear without scrollbars with the entire image visible in the resulting window.
looks like mozilla has similar issues, not sure if this is really a Gecko bug or not
Assignee: saari → pinkerton
related to bug 159410 - Popup windows do an ugly resize flash when shown, and can have unnecessary scrollbars? pink, you own that bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've also noted a strange behavior if the javascript must enlarge the window, it reach let's call it max size and then it's reduced by some pixels... Just as if JS was not aware that on OSX window decoration are larger. The easiest is to see it is to download my example 30 KB http://www.StocksRaiderS.com/donate/Donate-v1.1.htm.sit.hqx
Status: NEW → ASSIGNED
Target Milestone: --- → Chimera0.4
PPEmbed has this exact same bug. the window opens to the same size there as in chimera, which is too small and requires scrollbars. we must be missing code that's in seamonkey that somehow makes the content area bigger than what is requested. I put in NSLog code and we really are making it exactly as large as is asked for. conrad, any ideas here?
There are testcases in bug 159410. That bug also has an explanation as to why this happens: the page author makes the popup window the exact size of their image, but when gecko makes the document wrapper for the image, it adds a <body> tag that picks up style that has padding. So our content area is actually bigger than the image.
Hmm. Opening the screenshot of OSX on http://www.panic.com/audion/ with Mozilla and PPEmbed. The windows, when lined up on screen, show the width to be equal but the height of the Mozilla window is only about 4 or so pixels larger. These 4 pixels along the bottom cause the need for both scroll bars. Is there some small fudge factor in Mozilla when sizing windows? I'd have to set some breakpoints to know.
danm, any ideas here?
window.open(...width/height=x) goes through nsDocShellTreeOwner::SizeShellTo. This method is supposed to size the entire window so that the content area will magically end up at the given size. (Contrast this to window.open(...outerwidth/outerheight=x), which believes it already knows the final size of the complete window, and goes through nsDocShellTreeOwner::SetSize). Sorry; I don't have Chimera source handy. The nsDocShellTreeOwner used by embedded apps is embedding/browser/webBrowser/nsDocShellTreeOwner. Take a look at its SizeShellTo method. It's probably going through mWebBrowserChrome->SizeBrowserTo. mWebBrowserChrome should be a Chimera-specific window object. Its SizeBrowserTo will need to adjust for the size of the OS window borders. I'm guessing that's where the problem lies. This is kind of notoriously difficult to do on the Mac. (Have they fixed this yet with OSX?) If you can't just do it outright, have a look at nsXULWindow::SizeShellTo. That assumes the window has already been built and calculates the OS border widths using the extant difference between the size of the window and the size of the docshell. Or maybe I'm completely off-base. Let me know.
> This is kind of notoriously difficult to do on the Mac. Why?
> have a look at nsXULWindow::SizeShellTo. That assumes the window has already been built and calculates the OS border widths using the extant difference between the size of the window and the size of the docshell Yeah, that's what PPEmbed's nsIWebBrowserChrome::SizeBrowserTo() does as well. And, on stepping through it, the actual size of the content area (regardless of window frame) was made to be the requested size. The XUL window, on being passed the same numbers, ended up slightly larger. All that happened in both cases was the delta between current and requested size of the content area was applied to the outermost window. From that, I think the mac window widget was padded before this calc was made but I've yet to determine where :-/
Also, another difference in the widget case and the embedded case is that the widget version fires a resized event when the native window is resized. Maybe this is causing an additional reflow to happen which doesn't in embedding and this makes things good? It would be interesting to see if MfcEmbed has this problem as well.
So if we're not talking about actual window size, maybe we're talking about margins automatically added to content. Even in Mozilla, if you open a window with a requested inner size of (x,y) and fill it with contents of the same (x,y) size, you'll notice the window's docshell is indeed sized (x,y) but those contents are rendered offset a few pixels down and right and correspondingly clipped bottom and right. (IE does the same thing). You can make Mozilla stop doing this by removing the margins around the body element in a user style sheet. (Put a userContent.css file in your profile/chrome directory that looks like this:) body { margin: 0 0 0 0 } Sounds like what Simon was referring to in comment 7. Is this the problem you're seeing in Chimera? I think we shouldn't fix this. A web author could reasonably expect to see (x,y) worth of contents after opening a window with inner size (x,y). So it would make sense for us to slop up the size of the window by the body margins. But since everybody else (read: IE) does this same thing, I think web authors quickly realize they need to account for body margins and do so by hand. If we add body margin slop our windows will be too large, and we'll get complaints about that. Anomalously fat margins are in my opinion less of an error than clipped content. But I'm arguing that web authors will try their pages with IE and fix the clipped content.
This may help. It's a bundle of files including a (320x240) image that's obvious whether it's being clipped. Opening the image into a window that simply includes it as <img> contents shows all the funny problems mentioned in comment 14. However, open the image with fixed positioning at the upper-left and it looks fine. This works in Mac Mozilla, Windows Mozilla and mfcembed. It even works in Mac Navigator 4.x. I'm curious how it looks in Chimera.
> Sounds like what Simon was referring to in comment 7. Is this the problem you're > seeing in Chimera? Exactly. > I think we shouldn't fix this. A web author could reasonably expect to see (x,y) > worth of contents after opening a window with inner size (x,y). So it would make > sense for us to slop up the size of the window by the body margins. But since > everybody else (read: IE) does this same thing, I think web authors quickly > realize they need to account for body margins and do so by hand. If we add body > margin slop our windows will be too large, and we'll get complaints about that. I do see that IE add some slop, but IE doesn't show scrollbars in popup windows. I point once more to my testcase in bug 159410. Also, IE doesn't add body padding for image wrapper documents; loading a .jpg directly in IE shows the image in the very top-left of the window, with no padding. So I don't agree that we shouldn't fix this. We have control over the body margins for image wrapper documents. We should either set them to 0, or add padding for popups which we know contain such documents.
I stand by my observation that IE behaves the same as we. Though neither it nor Mozilla puts up scrollbars in this case. I wouldn't presume to dictate Chimera behaviour.
Whatever the content is, padded ot not, the problem is that when the inner size is set to (x,y), the eventual size ends up being different between Mac mozilla and Mac embedding apps (Chimera & PPEmbed). Check out the test case on bug 159410. Try it with mozilla (it will be lovely) and then with Chimera or PPEmbed. That difference is what we need to fix.
It's still wrong in mozilla; the image shows with body padding, while the window comes up in the specified size, so the bottom/right edges of the image are chopped off. I guess we should be asking why we don't show scrollbars in this case, even when Page Up/Page down cause the contents to scroll.
Target Milestone: Chimera0.4 → Chimera0.6
Target Milestone: Chimera0.6 → Chimera0.7
*** Bug 180406 has been marked as a duplicate of this bug. ***
Summary: windows opened via javascript appear too small → windows (popups) opened via javascript appear too small (have scrollbars)
ok, it's not chimera, ppembed does it too. mozilla isn't correct because it scrolls with pageup/down but shows no scrollbars. danm, how do we resolve this?
First, fix the body padding style, as I've said a bazillion times.
*** Bug 186462 has been marked as a duplicate of this bug. ***
Target Milestone: Camino0.7 → Camino1.0
*** Bug 232765 has been marked as a duplicate of this bug. ***
Depends on: 232765
Bug 232765 is fixed, so the body padding seems to be the main issue now.
which css file describes the body padding? is it something we inherit from gecko or are we setting it ourselves?
It's in html.css, and this change would have to be made XP. It would make it so that viewing a single image would show the image flush left/top in the window.
It's good enough for 1.0.
Target Milestone: Camino1.0 → Camino1.1
FWIW, stand-alone images hug the top-left corner in Safari.
Boris, comment 0 and comment 19 here describe the problem we're seeing and comment 27 describes what we'd like to do for parity with Safari on OS X. Is this reasonable in Gecko?
QA Contact: winnie → general
Target Milestone: Camino1.1 → Camino2.0
Attachment #95179 - Attachment mime type: application/octet-stream → application/ziop
Attachment #95179 - Attachment mime type: application/ziop → application/zip
Removing body padding in general would break all sorts of pages. Even removing it for just standalone images would be suboptimal; the little bit of space on the top left really makes the image display look better in general. There are no steps to reproduce using the original site, but let me see if I understand the problem correctly (based on the attached testcase and comments): 1) Both Camino and Firefox/Seamonkey make the content area the same size, as does IE. I just tested and so does Opera. 2) In Firefox/Seamonkey there are no scrollbars. Nor are there in Opera or IE (just tested). 3) In Camino there are scrollbars. Item 3 is a bug in either Camino or our embedding code. > I guess we should be asking why we don't show scrollbars in this case Yeah. The reason is that the window has features (width and height in this case) and those features do not specify scrollbars=yes. So the window that's opened does not have the nsIWebBrowserChrome::CHROME_SCROLLBARS chrome flag set and there should be no scrollbars. So what's responsible for following that flag and not doing its job? In xpfe/toolkit this is handled by nsXULWindow, and in fact the only the window creator has the info needed to apply this flag, so the window creator or someone it talks to needs to do it. I do see some code in camino/src/embedding/CHBrowserListener.mm (in CHBrowserListener::CreateChromeWindow) that uses this flag. Is this code hit in this case? Why is it not working?
Note that on trunk and 1.8 branch bug 114850 is fixed. Are you getting bitten by the security check or something? I'd think not, but could someone check?
Note also bug 324907.
Depends on: 324907
Mike, can you address Boris' questions in comment 31?
bz, i think the content area is just slightly too big and the content hasn't explicitly said "no scrollbars" so we overflow and get scrollbars. we looked at this for a long time a few years ago with danm and he was at a total loss. We're making the window exactly as large as it should be, but gecko is just giving us something that's a bit too big. That's why smfr suggested the body padding as the culprit. we do need an updated test case. hopefully smokey or ss can dig one up.
> and the content hasn't explicitly said "no scrollbars" Actually, it has. See comment 31, about the second half of it.
i meant in the example that started all of this, IIRC. As i said, we need to find a more up to date testcase.
So wait. The testcase in this bug shows a bug in camino (bug 324907, I guess). Is that testcase not representative of the original problem in this bug?
Here's another testcase: attachment 92773 [details]
That sets scrollbars=no, just like the testcase in this bug.
Maybe my patch in bug 324907 fixes this? When I try the testcase in comment 39, both windows come up without scrollbar and with the right size. Both do have a statusbar though. I'm not sure what the expected behavior is, but it looks ok. :)
Mass-reassign of bugs still assigned to pinkerton to nobody; filter on "NoMoPinkBugsInCamino".
Assignee: mikepinkerton → nobody
Status: ASSIGNED → NEW
Target Milestone: Camino2.0 → ---
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: