Closed Bug 309873 Opened 19 years ago Closed 19 years ago

No Content on the website with 1.0a1, but works with Camino 0.8.4

Categories

(Camino Graveyard :: Page Layout, defect, P2)

Product:
Camino Graveyard
Component:
Page Layout
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino1.0

People

(Reporter: mail, Assigned: mikepinkerton)

References

(
URL
)

Details

(Keywords: regression) 

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1

I wanted to do online-banking (http://www.volksbankbraunschweig.de/) and clicked
on "banking", left side, at the bottom.
Then the page goes to https://internetbanking.gad.de/banking/portal?bankid=9005,
but there is not content at all! It's a blank page. With the older version of
Camino, I get my fiels, can enter PIN etc .. and do my online-banking.
I also notice, that the mac is blocked for a few seconds when I use the new
browser-version ... so the "colour-wheel" starts for a moment when I go to other
camino-window because there opens a new window), before I can go one side back
or re-try to open the webside.
I tried to turn Javascript and all possible things on, accept cookies, ... but
it still does not work.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.volksbankbraunschweig.de/
2. Click "Banking", left side, bottom
3. You will come to https://internetbanking.gad.de/banking/portal?bankid=9005
4. You won't see any content on the webside. :-/

Actual Results:  
I close the blank webside (that opens automacitally by clicking on the
banking-link) and turn to the side before, and when I click there on something
(whatever ...) the colour-wheel starts turning for a moment.

Expected Results:  
Show the content, that is on the webside.
if this also happens in ff1.5b1 we can kick it over to core. can someone test?
Keywords: regression
weird, this works fine in ff1.5b1 but not camino. what on earth is going on here?
Status: UNCONFIRMED → NEW
Ever confirmed: true
tried turning off adblocking, no effect.
Target Milestone: --- → Camino1.0
Any chance this is related to the supposedly fixed bug 307821? I notice that
page does use FRAMESET.

cl
Bug 307821 was a trunk-only bug, so that's not it (its testcase for brokenness
works in Camino 2005092404 (v1.0a1+), anyway).

Ah, it's something to do with the JavaScript.  When I delete the JavaScripts
from the page locally, it suddenly displays.  

Specifically, the *second* instance of 

<script type="text/javascript" language="JavaScript"
src="../imagesPortal/Index.js"></script>

is the culprit.

Still no sense why it's Camino-only, but we have a couple of other Cm-only JS
bugs (295252).  But that's as far as I can take this one.
Related to bug 309712?
(In reply to comment #5)
> Specifically, the *second* instance of 
> 
> <script type="text/javascript" language="JavaScript"
> src="../imagesPortal/Index.js"></script>
> 
> is the culprit.

This doesn't sound like bug 309712 then.  Index.js is, in full:

var gStateMainIB="IB";
var gStateMainVrweb="vrweb";
var gStateMain=gStateMainIB;
var gSubmitMenu=false;
var gSubmitMain=false;
var gHistoryLengthVrweb=0;
var ibWidth = 800;
var ibHeight = 600;
var ibX = 20;
var ibY = 20;
if (screen.availWidth <= ibWidth) {
  ibWidth = screen.availWidth;
  ibX = 0;
} else {
  if (screen.availWidth <= (ibWidth + ibX)) {
    ibX = (ibWidth + ibX - screen.availWidth);
  }
};
if (window.outerHeight > ibHeight) {
  ibHeight = window.outerHeight;
};
if (screen.availHeight <= ibHeight) {
  ibHeight = screen.availHeight;
  ibY = 0;
} else {
  if (screen.availHeight <= (ibHeight + ibY)) {
    ibY = (ibHeight + ibY - screen.availHeight);
  }
};
/*resizeTo(ibWidth,ibHeight);
moveTo(ibX,ibY);*/

Looks like screen properties could differ between Camino and Firefox due to the
way Camino embeds Gecko.

/be
Bug 309982 may be similar.
When I copied the page source into a new document and added a <base href> tag
(instead of saving as HTML Complete as I did before), the page loads fine locally.

(BTW, scratch that "second instance" part of comment 5; it's only there once--I
was being dyslexic, or they've changed their code since yesterday.)
Summary: No Content on the webside with 1.0a1, but works with Camino 0.8.4 → No Content on the website with 1.0a1, but works with Camino 0.8.4
It seems that all that is necessary to trigger this bug is for Index.js to
access window.outerHeight. Weird.
Priority: -- → P2
The problem here seems to be that calling nsGlobalWindow::GetOuterHeight() does
a FlushPendingNotifications() on the HTMLContentSink very early on, before we've
detected the frameset. So we StartLayout() with the frameset flag set to false.

I've no idea why this might be Camino only. Maybe it's an embedding thing?
Is this still happening in a build with the patches for bug 312942 and bug
312097 in it?
For what it's worth, a current trunk TestGtkEmbed shows
https://internetbanking.gad.de/banking/portal?bankid=9005 fine...
Current Camino trunk: site loads fine.
Current Camino branch: site now partially loads (left and top frame), but the
inner frame is still blank.
Ah.  Bug 312942 hasn't landed on branch yet...  And this site has multiple
frameset tags.
Depends on: 312942
Please retest with tomorrow's branch builds?
There was no official branch nightly today, but I grabbed wrc_fan's 10-21 branch
build, and the inner frame with the login info is there now.

So FIXED via bug 312942.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.