Closed Bug 11847 Opened 25 years ago Closed 25 years ago

[PP] Linux/Alpha: Manually typed in URL doesn't work

Categories

(SeaMonkey :: UI Design, defect, P2)

DEC
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: niles, Assigned: radha)

References

Details

OK, first let me say that Linux/Alpha is working great. mozilla-viewer work perfect (well, as well and the i386 version). mozilla-apprunner also seems to have most of it functionality, however, if a type in a URL manually and hit return I only get the error message: JavaScript error: Components is not defined URL: file:////home/niles/mozilla/dist/bin/chrome/navigator/content/default/navigator.xul LineNo: 694 nothing loads after that. Again, mozilla-viewer entry field is working fine. Also, if I use any of the personal toolbar links in mozilla-appview pages load great and everything works. While the browser is loading I get: Assertion: "need to change SEGMENT_OVERHEAD size" (sizeof(PRCList) <= SEGMENT_OVERHEAD) at file nsBuffer.cpp, line 50 but I've already reported that and been told that that module will be replaced in M10. Also, if I select any of the menu items the browser crashes with: Program received signal SIGSEGV, Segmentation fault. 0x20004b31f40 in nsMenuFrame::Execute (this=0x1208aae90) at nsMenuFrame.cpp:928 928 mContent->HandleDOMEvent(*mPresContext, &event, nsnull, NS_EVENT_FLAG_INIT, status); (gdb) where #0 0x20004b31f40 in nsMenuFrame::Execute (this=0x1208aae90) at nsMenuFrame.cpp:928 #1 0x20004b2d138 in nsMenuFrame::HandleEvent (this=0x1208aae90, aPresContext=@0x1203bda00, aEvent=0x11fffefb8, aEventStatus=@0x11fffeee8) at nsMenuFrame.cpp:245 #2 0x200047ee48c in PresShell::HandleEvent (this=0x1203e7e80, aView=0x120853da0, aEvent=0x11fffefb8, aEventStatus=@0x11fffeee8) at nsPresShell.cpp:1877 #3 0x2000db49674 in nsView::HandleEvent (this=0x120853da0, event=0x11fffefb8, aEventFlags=8, aStatus=@0x11fffeee8, aHandled=@0x11fffee7c) at nsView.cpp:834 #4 0x2000db495dc in nsView::HandleEvent (this=0x1203e7820, event=0x11fffefb8, aEventFlags=28, aStatus=@0x11fffeee8, aHandled=@0x11fffee7c) at nsView.cpp:818 #5 0x2000db57d04 in nsViewManager::DispatchEvent (this=0x1203e74a0, aEvent=0x11fffefb8, aStatus=@0x11fffeee8) at nsViewManager.cpp:1609 #6 0x2000db4713c in HandleEvent (aEvent=0x11fffefb8) at nsView.cpp:66 #7 0x200001836a8 in nsWidget::DispatchEvent (this=0x1208a1b10, event=0x11fffefb8, aStatus=@0x11fffef58) at nsWidget.cpp:1144 #8 0x20000183168 in nsWidget::DispatchWindowEvent (this=0x1208a1b10, event=0x11fffefb8) at nsWidget.cpp:1008 #9 0x200001837dc in nsWidget::DispatchMouseEvent (this=0x1208a1b10, aEvent=@0x11fffefb8) at nsWidget.cpp:1171 #10 0x20000184eec in nsWidget::OnButtonReleaseSignal (this=0x1208a1b10, aGdkButtonEvent=0x1208425e0) at nsWidget.cpp:1764 #11 0x20000185e94 in nsWidget::ButtonReleaseSignal (aWidget=0x1208a1c40, aGdkButtonEvent=0x1208425e0, aData=0x1208a1b10) at nsWidget.cpp:2124 #12 0x20001c8f064 in gtk_marshal_BOOL__POINTER () #13 0x20001c3774c in gtk_handlers_run () #14 0x20001c36648 in gtk_signal_real_emit () #15 0x20001c338c4 in gtk_signal_emit () #16 0x20001c811dc in gtk_widget_event () #17 0x20001bf3ac8 in gtk_propagate_event () #18 0x20001bf24b0 in gtk_main_do_event () #19 0x20001dee170 in gdk_event_dispatch () #20 0x2000202f930 in g_main_dispatch () #21 0x20002030098 in g_main_iterate () #22 0x200020302bc in g_main_run () #23 0x20001bf1cd0 in gtk_main () #24 0x20000159470 in nsAppShell::Run (this=0x1201ca910) at nsAppShell.cpp:371 #25 0x20002e9339c in nsAppShellService::Run (this=0x1201cdab0) at nsAppShellService.cpp:468 #26 0x1200051c0 in main1 (argc=1, argv=0x11ffffba8) at nsAppRunner.cpp:754 #27 0x12000546c in main (argc=1, argv=0x11ffffba8) at nsAppRunner.cpp:821 #28 0x20002b55fb0 in __libc_start_main (main=0x1200053e0 <main>, argc=1, argv=0x11ffffba8, init=0x120003680 <_init>, fini=0x120009180 <_fini>, rtld_fini=0x11fffeb48, stack_end=0x11ffffb90) at ../sysdeps/generic/libc-start.c:78 I think this clearly points to the fact that SEGMENT_OVERHEAD wasn't big enough. But that's just a guess... I've tried changing SEGMENT_OVERHEAD form 8 to 16 so it's the same size as PRCList, but it didn't affect either of these problems. It just made the warning message go away. I'm running Linux 2.2.10 on an Alpha DP264, (the fastest machine in existance :) with RedHat 6.0 + updates. What can I try to debug this further?
Summary: Linux/Alpha: Manually typed in URL doesn't work → [PP]Linux/Alpha: Manually typed in URL doesn't work
Putting on [PP] radar.
Assignee: trudelle → don
Component: XP Toolkit/Widgets → XPApps
One bug to a report, please. I'm going to treat this bug report as the problem described in the summary, please file separate bugs for the 'also' problems. URL field is not an XPToolkit widget, reassigning to don
Assignee: don → radha
Priority: P3 → P2
Summary: [PP]Linux/Alpha: Manually typed in URL doesn't work → [PP] Linux/Alpha: Manually typed in URL doesn't work
Target Milestone: M11
Radha, any idea why it wouldn't work on an Alpha?
Status: NEW → ASSIGNED
Target Milestone: M11 → M15
Not a dogfood
With current builds: mozilla-viewer still works fine, but now NONE of the user controls in mozilla-appviewer do anything. None of the buttons, menu, or other control make anything happen. The menus do pop-down and the button go in and out, but it's as though nothing is hooked up with a call-back. It seems like it probably one small bug is the way the callbacks are registered. This is definitely DOGFOOD for Alpha/Linux. However, since it's not considered mainstream I guess that doesn't justify dogfood for the main Mozilla release. That's too bad. :(
I assume that my mozilla-appviewer you mean apprunner. I also assume you are using gtk. Please file a bug for the over-all "GUI does nothing" bug. I think if that gets resolved, this will automatically get resolved. Do you still get the Javascript error: Components is not defined message. That indicates that Javascript is not finding the dist/bin/components directory, which has most of the dlls required for normal function. I believe that clearing this will get you better mileage.
Depends on: 13601
I believe this is caused by 13601. apprunner/viewer work properly with my patch
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed by patch in 13601
Status: RESOLVED → VERIFIED
verified, old bug
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.