Closed Bug 170855 Opened 23 years ago Closed 23 years ago

Layout Viewer Test App has no URL bar

Categories

(Core :: Layout, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.2beta

People

(Reporter: kinmoz, Assigned: tetsuroy)

References

Details

Attachments

(1 file, 1 obsolete file)

In my Win32 Debug Mozilla build, the layout viewer test app has not had a URL bar since 09/23/02 ... I suspect it broke when MOZ_UNICODE was turned on in mozilla/widget/src/windows. After talking with yokoyama@netscape.com, it might be due to the fact that the following methods called during viewer startup, call nsWindow::Create() instead of nsWindow::CreateW(): nsBrowserWindow::Init() NS_CreateButton() nsBrowserWindow::CreateToolBar() NS_CreateTextWidget() nsThrobber::Init() We need to fix this so that some of the layout engineers who rely on viewer can still use it.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta
Attached patch needs WindowClassW() (obsolete) — Splinter Review
I know the problem is at http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#1473 where it calls WindowClassW() but derived classes (nsButton and others) didn't override the function. Thus the default nsWindow::WindowClassW() was called. However, I'm little puzzled with this test viewer app. I know I had a same problem (104934) and it was fixed by overriding WindowClassW(). But this viewer app _insists_ on calling the WindowClass() What am I missing here? Can one of you try my patch to see what's going on? I checked how the viewer app derives nsWindow quickly; but I failed to find clue.
Depends on: 104934
Yeah I'm seeing the same exact thing ... perhaps we have to do a complete clobber of the tree?
Comment on attachment 100735 [details] [diff] [review] needs WindowClassW() Btw, shouldn't all these changes be wrapped with |#ifdef MOZ_UNICODE| and the Makefile.in file modified to define it, like the changes in the widget dir?
The strange behaviour was due to the fact that nsWindow.h had MOZ_UNICODE where as viewer app didn't. Once we remove MOZ_UNICODE from widget, then we won't see this problem. (170852) kin: can you review/superview?
Attachment #100735 - Attachment is obsolete: true
Comment on attachment 102356 [details] [diff] [review] Needs MOZ_UNICODE sr=kin@netscape.com ==== For consistency, just remove the extra blank line after the |#endif| you add in nsTextHelper.h: +#ifdef MOZ_UNICODE + virtual LPCWSTR WindowClassW(); +#endif /* MOZ_UNICODE */ +
Attachment #102356 - Flags: superreview+
Comment on attachment 102356 [details] [diff] [review] Needs MOZ_UNICODE r=shanjian
Attachment #102356 - Flags: review+
Comment on attachment 102356 [details] [diff] [review] Needs MOZ_UNICODE a=asa for checkin to 1.2 (on behalf of drivers)
Attachment #102356 - Flags: approval+
This has approval. If it doesn't get checked in by the early morning tree closure on Nov 5, 2002 it's going to have to wait until after the branch is cut.
chris: this has already checked in few weeks ago. I should have marked it as FIXED. (however, the verification is pending due to 104934)
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: