The width is set to 296px and causes a scrollbar when using the Windows classic theme. I have no idea why a width is set on this div and I believe it should be removed / it isn't necessary.
btw: the file lives in /style/tignish/update.css
Is that popup going to happen with all the nightly updates or was that a one time test? (ie. If I pull out the width can we test it again?) Also, CCing steven who put it there.
Created attachment 358980 [details] screenshot going from 22.214.171.124 to 3.0.x We will be testing for a few more days so yes, you can pull it out. It was added in bug 470881 and I believe the one used for the test is located at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/bug470881/update.css Here is a screenshot going from 126.96.36.199 to 3.0.x using that same update.css to show that it is affected as well showing that it needs to be fixed at. http://www.mozilla.com/style/tignish/update.css
It looks like a width was given to it so the message could be centered on the page. Removing the width messes up the layout. The details-content <div> has a hardcoded width of 266px. Would that work better on both?
Created attachment 358986 [details] screenshot comparison I wasn't able to see any issue with removing the width. This is a screenshot with the Aero them but I also looked at it in Classic and it looks the same. Can you provide a screenshot showing the problem?
Is it the pushing down of the title so it is two lines? It seems that affect could be had in a better way than setting the width on the div
btw: lessening the width by two pixels also fixes when viewing this with the default Classic theme so lessing it to 266px would work. Still seems fragile having width on the div though.
It's noticeable when you load the page in a full browser: http://www.mozilla.com/en-US/firefox/3.0/details/ I trimmed it down to 266px in r21760. Give it a bit to get out to the website and let me know how it looks.
Doesn't the link for details get redirected to a different page when opened in the browser. I've been considering adding a separate attribute in the update snippet for the billboard url to separate it from the details url but haven't made it a priority since I thought it redirected. If it does redirect then it shouldn't matter what it looks like in the browser.
I don't know what URL loads in the client, but if it's the URL in comment #9 there is no redirection on my end.
I just tried it and I don't get scrollbars. However, it's not loading anything off mozilla.com, it's using: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/bug470881/update_test.html http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/bug470881/content.css http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/bug470881/update.css It's also worth mentioning content.css is a 404 there.
(In reply to comment #12) > I just tried it and I don't get scrollbars. > > However, it's not loading anything off mozilla.com, it's using: That was put there by nthomas for the update test in bug 470881. The same problem exists with our regular major updates which are served from mozilla.com (see previous urls and screenshot in attachment #358980 [details]). > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/bug470881/update_test.html > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/bug470881/content.css > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/bug470881/update.css > > It's also worth mentioning content.css is a 404 there. Not sure why nthomas chose not to also copy that file in bug 470881
The new width should be live. Is there anything else to do for this bug?
I just verified that the 188.8.131.52 to 3.0.5 Major Update no longer has the scrollbar when using Windows with the Classic theme. Nothing else needs to be done for this bug and thanks Wil!
Assignee: nobody → clouserw
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Re .../firefox/experimental/bug470881/content.css, there's a cron job that removes old files in experimental/, and wget had helpfully preserved the timestamp on content.css (last sept). I've downloaded it again, as well as the new update.css, and touched the files.
Component: www.mozilla.org/firefox → www.mozilla.org
Product: Websites → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.