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)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
VERIFIED
FIXED
mozilla1.2alpha
People
(Reporter: betz2010, Assigned: john)
References
()
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)
Comment 1•23 years ago
|
||
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.
Comment 2•23 years ago
|
||
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)
Comment 3•23 years ago
|
||
->DOM Style for investigation
Assignee: asa → jst
Component: Browser-General → DOM Style
QA Contact: doronr → ian
Comment 4•23 years ago
|
||
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
Comment 5•23 years ago
|
||
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
Comment 6•23 years ago
|
||
I meant HTML Frames, not HTML Forms. Do as I do, not as I say.
Reporter | ||
Comment 7•23 years ago
|
||
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
Comment 8•23 years ago
|
||
This is _not_ a problem with the page. This is a reflow problem that we have
with frames that have scrolling=no set.
Comment 9•23 years ago
|
||
I believe there is a possible work around... [sent email to Thomas]
Comment 10•23 years ago
|
||
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....
Comment 11•23 years ago
|
||
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
Updated•23 years ago
|
Summary: DHTML is broken on this site. worked in NS6.2.1 → Broken percentage width calculation in scrolling=no frame
Reporter | ||
Comment 13•23 years ago
|
||
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.
Reporter | ||
Comment 14•23 years ago
|
||
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?? :-((
Comment 15•23 years ago
|
||
> 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
Assignee | ||
Comment 16•23 years ago
|
||
This WFM Linux 2002031808 also. Windows-only?
Assignee | ||
Comment 17•23 years ago
|
||
Comment on attachment 74820 [details]
Testcase
Ack! Sorry, wrong bug. Bugzilla slowage is messing with my mind.
Attachment #74820 -
Attachment is obsolete: true
Comment 18•23 years ago
|
||
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?
Reporter | ||
Comment 19•23 years ago
|
||
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! :)
Comment 20•23 years ago
|
||
> 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)
Assignee | ||
Comment 21•23 years ago
|
||
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
Reporter | ||
Comment 22•23 years ago
|
||
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.
Comment 23•23 years ago
|
||
Thomas, the fix for bug 119849 landed last night. So the April 12th builds
should have the fix.
Assignee | ||
Comment 24•23 years ago
|
||
This wasn't fixed until last night. Try today's ...
Reporter | ||
Comment 25•23 years ago
|
||
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
Comment 26•23 years ago
|
||
See bug 119849 comment 48 and bug 119849 comment 55. This will be landing on
the 1.0 branch soon.
Comment 27•23 years ago
|
||
Verified on todays branch.
Status: RESOLVED → VERIFIED
Keywords: verified1.0.0
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
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.
Description
•