Closed
Bug 170855
Opened 23 years ago
Closed 23 years ago
Layout Viewer Test App has no URL bar
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.2beta
People
(Reporter: kinmoz, Assigned: tetsuroy)
References
Details
Attachments
(1 file, 1 obsolete file)
|
8.03 KB,
patch
|
shanjian
:
review+
kinmoz
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
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.
| Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta
| Assignee | ||
Comment 1•23 years ago
|
||
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.
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?
| Assignee | ||
Comment 4•23 years ago
|
||
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 6•23 years ago
|
||
Comment on attachment 102356 [details] [diff] [review]
Needs MOZ_UNICODE
r=shanjian
Attachment #102356 -
Flags: review+
Comment 7•23 years ago
|
||
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+
Comment 8•23 years ago
|
||
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.
| Assignee | ||
Comment 9•23 years ago
|
||
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.
Description
•