Closed Bug 124090 Opened 23 years ago Closed 23 years ago

Broken percentage width calculation in scrolling=no frame

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: betz2010, Assigned: john)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(1 obsolete file) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+)
Gecko/20020206
BuildID:    2002020603

Go to betz.li. This site has a 2 frames, the top contains the navigation (the
blue lines at the top) Click on a menu item (example webcam) and notice that the
color form the div gets lost. Try it in NS 6.2.1 where it works.  Now the really
strange thing is that it only is broken when the navigation is loaded into a
frame! Try loading the navigation frame directly and it works!
(http://www.betz.li/navigationNS.html)

The navigation validates as HTML 4.01 Transitional.
The CSS style sheet is here: http://www.betz.li/style.css
The JavaScripts are here: http://www.betz.li/scripts.js



Reproducible: Always
Steps to Reproduce:
1. Go to the URL
2. Click on the menu
3. See what happens
4. Check with IE or NS 6.2 where it works correct

Actual Results:  The Colors from the divs are lost

Expected Results:  They should not loose the color

Opening the navigation directly (http://www.betz.li/navigationNS.html) works
great, only broken when loading with frames (www.betz.li)
Extremely slick functionality!

I could reproduce what you describe: The light blue color is "sticky".
Strangely enough, after _reloading_ the page everything seems to work fine.

Build ID: 2002 02 04 09. Windows 2000.

My 5 cents :)

1) The script is crappy ;)
2) It seems to be a CSS problem

At the beginning, the 4 div's are set to 100% width
-> document.getElementById("nav4").style.letterSpacing = tt+"px";
after that.. the div's aren't 100%.. but they should
--> resize the window and the div's are again 100% in widht..

Maybe the frameset is broken? (and confusing mozilla)
AND: Mozilla reports JavaScript errors on the page! (Tasks/Tools/JavaScript console)



->DOM Style for investigation
Assignee: asa → jst
Component: Browser-General → DOM Style
QA Contact: doronr → ian
So after you click on the div and your scrollN() function occurs the divs are 
resized to the width of the content within the div, you can verify with: 
javascript: alert(window.navigation.document.getElementById
('nav1').offsetWidth);

So the question would be, Y does Moz resize the div?

I think it may be the doctype issue... window.navigation has a doctype of:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

This doctype renders the page in standards mode, this page should probably be 
rendered in quirks mode...

http://www.mozilla.org/docs/web-developer/quirks/doctypes.html


To HTML Forms.

Yet another scrolling="no" bug....  The top frame works correctly if you change
it to scrolling="yes".
Assignee: jst → jkeiser
Status: UNCONFIRMED → NEW
Component: DOM Style → HTMLFrames
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: ian → amar
Hardware: PC → All
I meant HTML Frames, not HTML Forms.  Do as I do, not as I say.
1. I know this script has waaaaay to much code, but it works in Netscpe 6, IE
and older Mozilla builds. (If you have suggestions how to make it better, send
me a mail! But I don't want to change the code just because its broken in
Mozilla...)
2. The navigation validates as HTML 4.01 Transitional:
http://validator.w3.org/check?uri=http://www.betz.li/navigationNS.html
So why should Mozilla render it in quirks mode?
Thanks for help
This is _not_ a problem with the page.  This is a reflow problem that we have
with frames that have scrolling=no set.
I believe there is a possible work around... [sent email to Thomas]
Blocks: 124431
Proposed work around, sent to Thomas:

  function init() {
      var w = "";
    w += window.innerWidth + 10 + "px";
    document.getElementById('nav1').style.width = w;
    document.getElementById('nav2').style.width = w;
    document.getElementById('nav3').style.width = w;
    document.getElementById('nav4').style.width = w;
  }

<body onload="init()">

this will set the width to a fixed number and prevent the bug, the only problem 
is that if the browser is resized the div's are not resized  so you get white 
space in the top frame.  But I believe there are scripts to reload the page 
when that occurs....
Summary should be changed to reflect the following:

Bug occurs within frameset with scrolling=no and div width set to 100%

If the div width is set to a px number bug does not occur
Summary: DHTML is broken on this site. worked in NS6.2.1 → Broken percentage width calculation in scrolling=no frame
scrolling=no -> 1.2.
Target Milestone: --- → mozilla1.2
Thanks for the workaround, but mozilla has still some issues with the site, so I
won't implement it. If you hover the first time over the navigation, they won't
change the color back to the original color. And the only thing the site does is
change the back- and foreground color of a div, either on "onMouseOver" or
"onMouseOut". (for example: "document.getElementById("nav1").style.background =
"#CCFFFF";"
Again, thanks to David.
Don't want to spam anybody here, but I just saw that this bug is marked for
Mozilla 1.2!?! Does this mean something which worked in Netscape 6.2 and until
at least Mozilla 0.9.4 will not work in the upcoming 6.5 (if this is the name)
and 1.0 release?? :-((


> Does this mean something which worked in Netscape 6.2 and until
> at least Mozilla 0.9.4 will not work in the upcoming 6.5 

It means that the guy the bug is assigned to is completely overwhelmed with bugs
and has no time to work on it....
Keywords: helpwanted
Attached file Testcase (obsolete) — 
This WFM Linux 2002031808 also.  Windows-only?
Comment on attachment 74820 [details]
Testcase

Ack!  Sorry, wrong bug.  Bugzilla slowage is messing with my mind.
Attachment #74820 - Attachment is obsolete: true
For what it's worth, I'm no longer seeing the bug on the original site with the
2002-03-18-06 Linux nightly.  I used to see it on Linux.  Has the site been
modified to work around this bug?
I'm running build 2002 03 19 on Win2k and I am still seeing the problem. The
DIV's are loosing the color when clicking on it. The site was NOT altered to
make it work. So is this windows only?
btw: the differences between 6.2.1 and a new mozilla build are amazing. It
starts so fast! :)
> The DIV's are loosing the color when clicking on it.

Doh.  I forgot the _click_ part.  My apologies.  This is present as ever on Linux...

(slaps head.  just hovering does a color change, which does not reflow, hence no
issues... hence need to click)
This seems fixed to me with bug 119849.  Definitely the width problem is gone. 
It seems like initially there are more white bars than usual though.
Depends on: 119849
I just tested it with build 2002041111 and the problems are still there.
Hovering the first time over the navigation bars keep them highlighted and when
clicking on it, the divs loose their color (there should be no white color)
Check with IE or NS6.2, they do what I want them to do :)
BTW: I tweaked the script a little bit to reduce the code, but the functionality
is still the same.
Thomas, the fix for bug 119849 landed last night.  So the April 12th builds
should have the fix.
This wasn't fixed until last night.  Try today's ...
You rock!! It's really fixed, you make me happy! I'marking this fixed...
One Question: Will this fix be in 1.0? I downloaded a build from the "latest
1.0" folder and it's not fixed with this build.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
See bug 119849 comment 48 and bug 119849 comment 55.  This will be landing on
the 1.0 branch soon.
 Verified on todays branch.
Status: RESOLVED → VERIFIED
Keywords: verified1.0.0
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: