Closed Bug 114196 Opened 24 years ago Closed 24 years ago

Menubar, logo and url bar turn black on load of URL

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 64049

People

(Reporter: rcgnaber, Assigned: attinasi)

References

(
URL
)

Details

Attachments

(6 files)

This is a screenshot of parts of mozilla gone black.
15.70 KB, image/png
Details
Reduced testcase, load it and move the mouse over the Mozilla menus -> black (at least on Linux)
812 bytes, text/html
Details
Even more reduced testcase
523 bytes, text/html
Details
Reduced testcase - no need for JS
289 bytes, text/html
Details
latest nightly (without TT AA)
117.16 KB, image/gif
Details
TT enabled build
100.49 KB, image/gif
Details
The menubar ans so on turn black after the page has loaded. Untouched items turn black also when you move the mouse over it (triggering a redraw). The browser does not crash. If you enter a new url (blindly) and load the page, items will turn to normal (either by themselves, or by triggering a redraw).
Upon loading of this page, it makes the impression of "flashing" in black. I think that's because it loads a background image. However, I was unable to trigger the flashing behaviour you mention by hover over links or whatever. Everything seems to work fine for me. I'm using build 2001-12-05-04 on Windows 98. -> blind guess, ImageLib
Assignee: asa → pavlov
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston
Also, when I have loaded the URL and switch away and back again in virtual desktops in X, the screen is completely black, except for some imagery from the different virtual desktop and hence becomes totally unusable.
That's a quite old build. Can you download the latest nightly and re-try?
Sorry for not thinking of that one. It's the same story on the latest nightly: build 2001120721.
hey,confirming using build 2001120712 on Linux, that's the first time I see this kind of problem. Perhaps some CSS interacting with own Mozilla's CSS ? I don't know which component it should belong to though. Severity -> Critical because black partsappearin existing windows.
Severity: normal → critical
The bug seems to deal with some Flash applet being loaded within an IFRAME tag. When using a sniffer, the other file retreived loads a Flash ad.
No, it also happen without Flash plug-in (still using build 2001120721 on Linux).
Removed JS code. Still shows the bug.
Got same result with linux build 2001120720 using attachment 60952 [details]. But even better, I tried it with 0.9.6 under XP Pro and the browser hangs. No screen redraws, no menus are responsive, the animated moz icon stops. However, the windowx close (X) box in upper right corner of app DID close the app and the task manager did NOT say the app was not responding... Reproduced the hang three times under XP and 0.9.6
current cvs linux shows the same behaviour. Context-menus go black as well - I don't think this is imglib. Frames? Confirming, adding blizzard to CC
Status: UNCONFIRMED → NEW
Ever confirmed: true
over to layout
Assignee: pavlov → attinasi
Component: ImageLib → Layout
QA Contact: tpreston → petersen
This is caused by too large WIDTH in IFRAME element. Testcase e.g.: <html> <body> <IFRAME SRC="http://www.mozilla.org/images/mozilla-banner.gif" WIDTH=60000 /> </body> </html> For me the critical value is WIDTH=1025 (Linux, 2001120906, 1024x768 X); in that case it is possible to recover by hitting the "back" button (already black), but not for larger values. IMG and OBJECT are not affected.
related/dup of bug 91747
Well, bug 91747 does not show the same behaviour (the black stuff) on linux, since it is about a large iframe height value instead of width (too large a height value is not a problem for linux it seems). Bug 64049 (which is mentioned in the comments of bug 91747) however does show the same behaviour as this bug (114196), because the testcase has large width and large height values. My question: mark it as a duplicate of 64049 and enter some comment about linux behaviour in that bug or leave as it is?
Attached image TT enabled build —
forget those - wrong bug!
Since there was no response to my question, I am assuming nobody has a strong opinion on the matter and I'll mark this bug as a duplicate to bug 64049 (assuming I can). *** This bug has been marked as a duplicate of 64049 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: