I knew there was a reason I didn't really want to upgrade, but I did & now the FF15 won't display the htm which my old version did perfectly
Actually it does display the page, but it doesn't display some of the elements which 3.6 did perfectly & even lowly old IE9 still does Where do I post the 2 screenshots? - the 1 of IE9? & the other of FF15? - which, it should be obvious, isn't displaying the blue lines down the sides
모든 댓글 (6)
You can't attach a screenshot to the first post that starts a thread, but you can do that in subsequent replies.
Can you post a link to that site?
The site in question is an HTM document of my making It's exactly the same document - it just doesn't display the blue lines on either side the way these screenshots show My previous version of FF (3.6?) displayed them perfectly too
Do you know what (CSS) code is responsible for those lines?
They may be using the -moz prefix to set the color and that property may no longer be supported.
Mozilla removes support for the prefixed version at some point when the implementation of a property has been finished.
cor-el wrote: Do you know what (CSS) code is responsible for those lines?
After you asked your question, I did some experimentation by varying the size of the jpg displaying the long blue bar & came to a startling conclusion
FF15 has changed its ability to display jpgs, if said jpg is even slightly greater than 30K on its long (vertical) side
You see, the blue bar isn't generated by FF - it's an independent 8x35Kblubx.jpg, an 8 x 35,000 pixel blue line, which was custom created in a drawing prg
I can send you the file if you want to see it, but the bottom line is, the old version of FF used to display it perfectly & in virtually any paint type or jpg display prg (preferably such as IrfanView or ACDSee etc), it still will, but NOW, in FF15 it doesn't work
Thus whoever's responsible for finalizing the code at Mozilla/FF (whether it's a committee or a person making a decision for a committee), they've decided some type of jpgs just won't display, if they're greater than some arbitrary # of pixels on its long (vertical) side
So, here it is ; even FF15 runs the HTM perfectly, *if* I restrict the 8x35Kblubox.jpg to its shorter `brother', which is 8x30Kblubox.jpg
Why 30K is acceptable to FF15, but even 30.5K or certainly 34K isn't, is completely upto whoever's responsible for deciding what will display on FF15
All right, why the change? - Even IE9 still displays the 35Kblubox & all the way upto 60K & maybe more (I decided 60K was as big as I'd need at the time they were created), but FF15 jams out at 30.5!
Clearly it's a FF15 `issue' & should be restored to its former ability to run at least 60K pixel or greater jpgs (along the long upright edge)
frebe
The limit is probably 32767px on Windows as I've seen this more often reported (this doesn't happen on Linux).
- Bug 671302 - cairo-gdi: large background-images and gradients don't work beyond ~ 32735px
- Bug 591822 - Images taller or wider than 32767 (signed short overflow limit) 96DPI pixels fails to be rendered
Cor-El,
If IE9 can display my 60K px bars on the same W7 system & especially since FF3.6 displayed the 60K bar without a trace of a problem, doesn't it make you think the problem's in FF15 & not in some DoZZZe limit?
Besides, if other users have reported this similar pixel display problem, assuming there are programmers at Moz/FF who can program the problem away, the question is, why haven't they?
frebe