For some reason, Mozilla Firebird has difficulty rendering the tables correctly at Litestep.net. The left side of the tab with News on it is repeated about 40 times, shifting the content to the right. Refreshing always fixes this.
Has anyone else noticied this with Firebird?
yup, but it's been happening to me with many pages (mostly using e107)
opera 7.20 looks great :P
yah...its a problem with the Firebird/Phoenix system. For some reason the div's do that and there is nothing siteside we can do about it. I use Phoenix and to get around it I just refresh...hopefully that works for you too.
I've gotten this on Firebird and the Mozilla Suite, but it's only about 1/50 times, if that.
happens with Netscape Navigator also (not a surprise cus NN uses Mozilla's engine).
Firebird .6.1, then .7, and Mozilla 1.4 and now 1.5...only happend once so far. Kinda odd.
happens almost every page load for me with firebird 0.7 Didn't happen with 0.61. I tried a cvs build shortly after 0.61 and it was already happening then as well.
Yes it does happen. Refresh helps. Anyone filed a bug with mozilla yet?
same here jugg.
i never saw this with 0.61, but 0.7 loves screwing up the news page on ls.net
infact, it's only this site, and only the page you see immediately after logging in which is b0rked here
This is the only site I've seen this happen on so I find it hard to believe it's a Firebird problem and not a problem with the site.
mst asked "Does Anyone filed a bug with mozilla yet?"
The site code checks out with W3C still. I also have issues with fixing "bugs" that only appear with a certain browser.
There are a few bugs in bugzilla that look like they might be related, but it's really hard to find the bug you're looking for...
I just ran it through the validator and it does NOT validate. Although nothing that it finds is likely to cause this problem.
Just an FYI
All that there really appearts to be is that it doesn't like the TR and TABLE being closed.
The width it offsets is clearly 100%. So is the width of the table where it starts the offset.
1. OK, so there's table at 100% width.
2. There's a cell in that table that is then (erroneously?) caused to span that 100% width.
3. Then, beside it, in the next cell, is another table, also 100%, told to span another 100% of the parent width.
I wish I could make this problem occur offline, though.
Also, the errors after the one for INPUT are a bit odd. Unfortunately I don't have the means nor caffiene level to see if those tags are indeed not open somewhere.
last I checked all of the "non-validations" are required to make the site work. Items like "name" are required...and POST and post being different...well thats just crazy talk.
I don't know about POST, there...
If body is not the same as BODY, why would POST be the same as post?
http://www.w3.org/TR/xhtml1/#h-4.2
"XHTML documents must use lower case for all HTML element and attribute names. This difference is necessary because XML
is case-sensitive e.g. and are different tags." (emphasis added)
OTOH, it will be years before a browser doesn't get it right.
My previous comments based on
http://www.doddstech.com/ls.html, this page, a bit back, saved as a text file from Firebird.
http://www.doddstech.com/check.html is the validator's result saved and uploaded.
It's easy to see that the problem Firebird is having when rendering LS.net is not a fault with LS.net.
The repeated corner is simply because this table cell has a CSS class with a repeated background. If the class was changed from ...
.tablf { background-image: url(../images/tabs/tab_lightleft.gif); width: 5px;}
... to ...
.tablf { background-image: url(../images/tabs/tab_lightleft.gif) no-repeat; width: 5px;}
... you would only see one corner image but the table cell will still be as wide and push the content over to the right.
I believe the problem is that Firebird is making an assumption about the width of the column before it's recieved all table tags. Perhaps because it's recieving the information too slowly. Which is why when you reload the page it displays correctly, since it already has all the code, it just needs to draw it again.
I believe this problem can easily be corrected by using colgroup and col tags to define the structure of the columns in a table. The user agent will get this information before receiving all the data for the table and therefore won't have to guess the structure as it's rendering it.
The style bit could be the problem, but I've never had it occur on anything but the forums. Am I alone in this? If not, it seems some of the table tag closing tag issues might matter--this page's tables do not validate as XHTML 1.1.
Its strange because if there was a large DB call right after the first image I would understand...but there isn't. It uses some included variables to get the tab names and that is it, so there should be no delay.
as for the tag closing...it is because there are multiple tags on each line. if you look at where and should be they share a line with something else which makes the validator whine.
"The style bit could be the problem"
No it couldn't, and wasn't what I was suggesting. I was just explaining why the corner image was repeated 50 times. A background image will have (should have) no effect on the width of the column.
"Its strange because if there was a large DB call right after the first image I would understand"
By first image, do you mean the corner image of the news tab? The only image in the HTML is images/blank.gif. But what we see is the image used as a background defined in the style sheet. I don't think a DB call at this point would have any effect. Especially since I would have throught the page would be completely parsed before being sent to the user agent.
"as for the tag closing...it is because there are multiple tags on each line"
I validated the this thread with the W3C validator and it defintely looks like on line 113 should not be there. There's also a on line 413 which was reported to be out of place but it's difficult to tell. I don't think this is causing the problem with firebird though.
COLGROUP shouldn't be necessary since the width of all tables and cells have been well defined in the CSS but it's the only thing I can think of that would correct the problem since Firebird doesn't seem to know how wide that column is until the page is fully downloaded.
All table, td, etc are closed. There are a number of unclosed br and img elements though, as well as the meta and link in the header. After adding tons of '/'s to close those and pretty printing there are 4 errors, one of which is probably required (target attribute).
Are you sure about that </td> on line 113? There is already a </td> at the end of line 112. You can't have a </td> followed by another </td> without a <td> or </tr><tr> between them. It might match to an opening <td> somewhere but you can't overlap table definitions. They have to cascade.
But like I said, I don't think it's causing the firebird problem anyway :)
That's odd... that </td> isn't in the copy I tested...
Ok, it doesn't help that Mozilla mucks up the html source when it saves it... All those br and img elements ARE closed in the original, and it looks like there might actually be a stray </td>. :6
Save as HTML only. With Web Page, Complete, it changes the code.
Also, this is a pretty big set of tables. It seems problems with tables might have something todo with it, but it isn't doing it all the time. If it happened on any other site, particularly one that could be accessed by anybody w/o logging in, I might bother to drop by bugzilla about it.
"It seems problems with tables might have something todo with it..."
It's an error, but an error I expect most browsers will tollerate. The fact that when you save the web page the tag disappears says to me that the browser recognises that it's not meant to be there and ignores it. Even if it is meant to match up with a <td> somewhere it won't matter if it's ignored since </td> is optional and not required in table definitions.
I believe the bug with Firebird is that it's not adopting with width specified for this column in the CSS.
OK, Firebird problem confirmed, for me anyway, as of about 2 minutes ago:
http://www.doddstech.com/anand.jpg
we know that it is there...we just don't know why or what to do about it. if anyone wants to look at the code or the image I do have a copy.
Send it on and if I get time I'll take a look.
this also happens with k-meleon 0.8.1, but it happens nearly every time i open a page, and even occasionally after refresh
For some reason it happens to me after i write a comment, and only then. I am using modzilla and i imagine they use the same engine
I have good news for all of you that complained. The Firebird bug that plagued LSnet was corrected in last nights "nightly release."
LINK
Well I just got it in Firefox. :P
In fact, I'm getting it a lot more often with 0.8 than I did with 0.6.1
So I'm guessing they must have fixed that after the branch. :(
Looks like Official .8 is broken...that nightly linked there does work though. Haven't had a single problem in 3 days.
Looks like that link is to a generic nightly. Here is the link to the specific one so there is no "well it doesn't work for me" crap.
LINK
Using Firefox .8
If you click the little tab on the bottom left corner of
the browser, you can switch style sheets.
Switching from "default style" to "basic theme" seems to fix it.
It does seem to fix it... but you have to set that silly thing for every page that you load. Oh how I hate to use internet exploder. Wish I knew soemthing, I would be more than happy to help.
I'm using Moz Fx build 0.8+ 20040211. While I still get this problem, I don't get it nearly as much as I did with the official Fx release.
I'll take a close look at the CSS and Source to see what I can come up with. I do think it's most likely a problem with Moz Fx.
Btw -- This site isn't XHTML 1.1 compliant. Might want to remove the button. :)
Refreshing always fixes this.
I bet it has to do with the internal Moz Fx rendering engine and the lag the server shows when printing the main content.
Fix? Anyway to speed the server up? The server is lagging when rendering the central content table. By that time the table has already drawn. Width: 100% might be messing it up in that you're missing px and % width. This has always been a problem I think with netscape (not sure on other browsers).
Maybe for a fix, set a min width value and kill the 100% width for br1t?
The "lag" is not server side. I get the reoccuring image all over the site, not just while pending a page load. Also...if it were a site issue I wouldn't be able to fix it with a different build of FireFox...nor IE.
I'm using Mozilla FireFOX 0.8 and i still got the same problem. I used to have it with fileplanet.com on netscape a while ago. Although for a fact refreshing does NOT always fix it, this very thread is beeing shown off screen to me, i refreshed it after reading the post above and it's still the same. I sometimes refresh helps, sometimes it doesn't, although i've found that in a strange way this happens on ls.net pages opened in tabs. It doesn't seem to affect pages in the very first tab.
download the nightlies that I linked to.
Firefox 0.8
Glad I'm not the only one
Only I connect at 26400 kbps
at home an refreshing is a
time time consuming project I
just side scroll Switching to
basic theme seemed to fix it
thanks
again...download the nightlies I linked to.
Ok, but how do I get basic theme to "stick" for me? Everytime I change a page, I have to reset the basic theme.
win98se/firefox0.8
I'm glad this is documented as firefox's problem. has anyone submitted this to mozilla's bugzilla?
Obvously it has been submitted, because it has been fixed. Get a reasonably recent nightly and watch the problem disappear.
