Closed Bug 1755 Opened 26 years ago Closed 25 years ago

Background image disappears

Categories

(Core Graveyard :: Embedding: APIs, defect, P2)

Product:
Core Graveyard
Component:
Embedding: APIs
Platform:
x86
Windows 95
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: run2000, Assigned: nisheeth_mozilla)

References

(
URL
)

Details

Select the "Customer Service and Sales Team" link near the top of the page. Notice it is a mailto link, and should have no effect on rendering of the page. Now maximize the browser window. The background image now disappears, and the page renders the white color underneath. All other images render ok. This occurs on the 19981203 build of both viewer and xpviewer.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
works fine in current build.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Re-opening. This bug is still taking place on the 1.28.99 Win32 and Mac OS builds of Viewer. (On Mac OS, just click on "Customer Service & Sales Team" to invoke this problem.) Can't reproduce on Linux, however.
Assignee: michaelp → joki
Status: REOPENED → NEW
Component: Rendering → Event Handling
since a click event triggers the problem, let's start there... you can also use default_c.htm instead of default.htm to help narrow things down (it's not related to the frameset).
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Using this code <html> <head> <title>Dispearing bg image</title> </head> <body topmargin="0" leftmargin="0" background="legal_t1_tile.gif" bgcolor="#FFFFFF" link="#330099" vlink="#660000" alink="#336600"> <a href="mailto:foo">Ordering</a> </body> </html> with the image from http://www.brookers.co.nz/legal/images/legal_t1_tile.gif greatly simplifies this. You don't even need to resize to see it. The page is trying to load the mailto and somehow the bg image goes away even though the content stays. Probably not mine but I'll keep looking.
Status: NEW → ASSIGNED
Target Milestone: M4 → M5
Not critical for M4 at this point, moving to M5
Assignee: joki → troy
Status: ASSIGNED → NEW
Troy, Kipp suggested I sling this your way and let you take a look at it. Basicially whenever we go to a bad url the document seems to partially unload. Background images go away but content stays.
Web shell issue. Nisheeth, here's what is happening. The reason the background won't render after clicking on the link is that the pres context's StartLoadImage() code returns because "mStopped" has been set. "mStopped" was set in the pres context's Stop() function which was called by the web shell's Stop() function. See the stack trace below. Basically the problem is that the web sehll's DoLoadURL() stops the loading of the document before we load the new document. We should wait until after we know we're replacing the current document with the new document. nsPresContext::Stop(nsPresContext * const 0x0152af50) line 758 DocumentViewerImpl::Stop(DocumentViewerImpl * const 0x015289d0) line 374 nsWebShell::Stop(nsWebShell * const 0x014c6100) line 1523 nsWebShell::DoLoadURL(const nsString & {...}, const char * 0x01888ab8, nsIPostData * 0x00000000, nsURLReloadType nsURLReload, const unsigned int 0) line 1392 nsWebShell::LoadURL(nsWebShell * const 0x014c6100, const unsigned short * 0x10039198 unsigned short * kCommonEmptyBuffer, const char * 0x01888ab8, nsIPostData * 0x00000000, int 1, nsURLReloadType nsURLReload, const unsigned int 0) line 1513 + 28 bytes nsWebShell::LoadURL(nsWebShell * const 0x014c6100, const unsigned short * 0x10039198 unsigned short * kCommonEmptyBuffer, nsIPostData * 0x00000000, int 1, nsURLReloadType nsURLReload, const unsigned int 0) line 1340 nsWebShell::HandleLinkClickEvent(nsIContent * 0x0392294c, nsLinkVerb eLinkVerb_Replace, const unsigned short * 0x10039198 unsigned short * kCommonEmptyBuffer, const unsigned short * 0x10039198 unsigned short * kCommonEmptyBuffer, nsIPostData * 0x00000000) line 1978 OnLinkClickEvent::HandleEvent() line 1812 HandlePLEvent(OnLinkClickEvent * 0x039281f0) line 1825 PL_HandleEvent(PLEvent * 0x039281f0) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0147f300) line 437 + 9 bytes _md_EventReceiverProc(HWND__ * 0x002301ee, unsigned int 49301, unsigned int 0, long 21492480) line 799 + 9 bytes USER32! 77e71268() 0147f300()
Assignee: troy → nisheeth
Component: Event Handling → Layout
Status: NEW → ASSIGNED
Component: Layout → Embedding APIs
Accepting bug. Setting component to Embedding APIs
*** Bug 4950 has been marked as a duplicate of this bug. ***
Moving bugs of lower priority to M6...
Moving non-crashing layout and webshell component bugs to M8... I already have enough blockers and crashers for M6. If I fix them in time for M6, I'll move some of these bugs back to the M6 milestone. I'm keeping the M7 milestone for fixing XML bugs.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
I just checked in a fix for this bug. I separated out the functionality of nsWebShell::Stop() into two methods, StopBeforeRequestingURL() and StopAfterURLAvailable(). The former is called from nsWebShell::DoLoadURL() before sending a new URL load request to the doc loader. The latter is called from nsWebShell::OnStartURLLoad(), the notification to the webshell that the stream created from the new URL is valid, available, and ready to be consumed. Now, when we click on the mailto link, only StopBeforeRequestingURL() is called. StopAfterURLAvailable(), which stops the content viewer and the pres context, is never called until after the URL is verified as a valid, available URL.
Status: RESOLVED → VERIFIED
Verified on 1999-07-19-12-M9 builds.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.