Closed
Bug 7417
Opened 26 years ago
Closed 25 years ago
[PP]Linux: Flakey startup, menus disappear, resize not working
Categories
(Core Graveyard :: Tracking, defect, P1)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
M9
People
(Reporter: mcafee, Assigned: warrensomebody)
References
Details
(Whiteboard: [PDT+]have workaround for m7, this is randomly reproduceable and ugly without it,)
Attachments
(4 files)
Linux, gtk 1.3 (tip of both mozilla & gtk)
Start up apprunner, you need to resize the window
to get content to show up. Also, possibly related,
the menubar has disappeared and I can't resize to
content larger than the original size (both horiz.
and vertical resizing look broken). CC-ing some people
so we can narrow this down.
Reporter | ||
Updated•26 years ago
|
Target Milestone: M7
Reporter | ||
Comment 1•26 years ago
|
||
Here's what I see on startup:
ftp://mocha/mcafee/bugs/7417/7417.gif
resizing the window wakes up the content,
but the menubar never shows up. viewer does
not have this problem.
Reporter | ||
Comment 2•26 years ago
|
||
[akkana says in mozilla.builds:]
With a build pulled Tuesday morning around 10:15am, the first time I
ran apprunner everything worked great, but the second and third times,
I saw all the problems Chris describes.
Comment 3•26 years ago
|
||
I don't see this problem when i run apprunner by hand... setting LD_LIBRARY_PATH
and MOZILLA_FIVE_HOME to dist/bin, but i *do* see this behaviour when i run the
app using mozilla-apprunner.sh
Comment 5•26 years ago
|
||
This problem comes and goes. Furthermore, it seems to come and go for different
people at the same time (Chris and I both saw it at the same time, then the
problem went away for both of us at the same time). I'm guessing that maybe
it's related to the netlib-flaky-loading bug (which previously only showed up
with images), 3291.
Reporter | ||
Comment 6•26 years ago
|
||
I now notice that pulling my machine off the network
hangs the rendering process before it gets to the menus,
maybe we're hitting a network problem as Akkana suggests?
The resize event might be "trying again" which is working?
Comment 7•26 years ago
|
||
I also saw this bug after I updated and built my tree this morning. I am doing a
clobber build now to see if it is any better.
The flash panel does a sychronous load to grab the flash information. Maybe it
is hanging because that page is not loading properly? Waterson has another bug
on that.
Also, Paul MacQuiddy reported that the bookmarks are not loading properly on any
platform. That may also be holding things up. He said that even the "Manage
Bookmarks" dialog is not working.
Reporter | ||
Comment 8•26 years ago
|
||
It's baaaack. I cannot track down what is causing
this, it appears to be slightly-random for me.
Timer bug? Old pentium bug? ;-)
Comment 9•26 years ago
|
||
Scratch what i said earlier; rerunning enough times, i eventually reproduce the
naughty behaviour.
Reporter | ||
Updated•26 years ago
|
Severity: normal → blocker
Priority: P3 → P2
Summary: Linux: content needs resize event to trigger rendering → [Block] Linux: content needs resize event to trigger rendering
Reporter | ||
Comment 10•26 years ago
|
||
Raising priority, marking as "stability" blocker.
Summary: [Block] Linux: content needs resize event to trigger rendering → [PP]Linux: content needs resize event to trigger rendering
Reporter | ||
Comment 11•26 years ago
|
||
Looks like mail/news is having the same problem:
http://bugzilla.mozilla.org/show_bug.cgi?id=7478
Not duping this until we know a little more about what's
going on.
Reporter | ||
Updated•26 years ago
|
Summary: [PP]Linux: content needs resize event to trigger rendering → [Blocker] [PP]Linux: content needs resize event to trigger rendering
Reporter | ||
Comment 12•26 years ago
|
||
Sorry, I consider this a blocker.
Resummarizing. If you feel differently,
please add a comment and mark it so.
Priority: P2 → P1
Summary: [Blocker] [PP]Linux: content needs resize event to trigger rendering → [PP]Linux: content needs resize event to trigger rendering
Comment 13•26 years ago
|
||
And a P1 to fix please!
Comment 14•26 years ago
|
||
This doesn't seem to have anything to do with the sidebar. If I change the
sidebar to be about:blank, the menubar comes up, but the menus are still blank.
Also, the resizing is still messed up.
Comment 15•26 years ago
|
||
RE: Linux 6/1 build (1999-06-01-08 m7)
I have seen some problem similiar to this:
Yesterday evening, I sent my mail test account qatest38 several mail messages
with an attached jpeg image. I could view the jpeg image on win_nt 4.0 using the
6/1 seamonkey build, and 6/1 seamonkey build on Mac but I cannot view it on
Linux 6/1 seamonkey build
2. Then I used the 4.6.1 build, I could view it on solaris 2.51 but I cannot
view it on Linux. All I saw was a broken image icon. I sent several mail with
the attached jpeg. Still could not view it on my linux box.
3. However, this morning, using the same Linux build (6/1) and viewing the same
mail messages on the same Linux box, I could view the jpeg image in each of the
mail messages. I thought it was my machine problem because Seth said he had no
problem.
Comment 16•26 years ago
|
||
*** Bug 7478 has been marked as a duplicate of this bug. ***
Comment 17•26 years ago
|
||
OK, this problem seems to appear and then disappear for everyone at the same
time. Two hours ago it was happening consistently, and then an hour ago it
stopped happening consistently. And now it's back.
I've been in and out of slamm's cube this afternoon with most of the xheads and
it's our best guess that since this starts and stops happening to everyone at
the same time, it is likely some weird network or timing problem. But we don't
know how to even debug it.
I talked to Warren and he says that Rick Potts might be able to figure it out if
it's actually a netlib problem.
Other than that, I don't know what to do with this bug. Chris, what should I
do? Re-assign this to rpotts?
Comment 18•26 years ago
|
||
Apprunner runs fine this morning. I am running the same bits I used yesterday
when it was broken.
The menus show up, all the content loads, and even resize works properly.
Comment 19•26 years ago
|
||
As of 10:00 it is broken for me with today's builds :-(
Comment 20•26 years ago
|
||
Yep, it is broken again. I tried replacing the home page here are my results:
homepage (set in navigator.xul) results
--------- -------
http://www.mozilla.org/ broken
http://www.uiuc.edu/ works
http://www.yahoo.com/ works
http://photo.net/ works
http://www.cnn.com/ works
bad url works
http://cvs-mirror.mozilla.org/webtools/tinderbox/showbuilds.cgi?tree=SeaMonkey
broken
not found url on mozilla.org works
mozilla pages copied to my server works
unwrapped mozilla.org page works
So, it seems to have something to do with the way mozilla.org is serving up
wrapped pages.
Comment 21•26 years ago
|
||
Slamm, you have manus working when you change the start page?
Comment 22•26 years ago
|
||
Yes, menus work when I change the start page. Then, if I go to
http://www.mozilla.org/, the menubar stays, but the menus only come up as tiny
empty boxes.
Reporter | ||
Updated•26 years ago
|
Summary: [PP]Linux: content needs resize event to trigger rendering → [PP]Linux: Flakey startup, menus disappear, resize not working
Reporter | ||
Comment 23•26 years ago
|
||
Resummarizing. Yes, changing the home page from
http://www.mozilla.org/quality/smoketests
to
http://www.apple.com
fixes everything. I also tried other pages
at mozilla.org, no go, this seems to be failing
with mozilla.org pages.
Comment 24•26 years ago
|
||
Mozilla.org has long shown a tendency to trigger sporadic sometimes-not-loading
bugs in our code -- see 3291 for more history on that.
Comment 25•26 years ago
|
||
I didn't run into this for a couple of days, but I am again today. Same deal:
June07 Linux build started out fine, became broken after a restart. Can't really
use it for testing like this....although resizing does allow a message to draw,
the resizing has to be done for every message, and it still doesn't enable the
mail menus.
Comment 26•26 years ago
|
||
Sorry; if I change package/chrome/messenger/content/messagePane.xul to use
another home page, in analogous fashion, the workaround DOES work.
Updated•26 years ago
|
Assignee: chofmann → dp
Comment 27•26 years ago
|
||
dp said he would try to contribute some analysis to this...
Comment 28•26 years ago
|
||
Messenger has the same problem.
The messenger start page is http://www.mozilla.org/mailnews/prefs-info.html
(see mozilla/dist/bin/chrome/messenger/content/default/shareglue.js)
So on Linux messenger, we get the same bug: no menus, resizing not working.
If I save prefs-info.html and 7 gifs used by the page to my disk, and change the
start page to
file:/u/sspitzer/chupadocs/7417/mailnews/prefs-info.html, it works, I get menus,
and #7417 doesn't happen to me.
If I use enterprise server 3.6 (on solaris) and set the start page to
http://chupa/sspitzer/7417/mailnews/prefs-info.html (which is really
/u/sspitzer/chupadocs/7417/mailnews/prefs-info.html) it works.
wild off the wall guesses:
1) netlib problem on linux?
2) perhaps it is an apache / mozilla combination problem. I've seen this with
slashdot and 4.x on linux. some times, pages never seems to load. if the page
never finished loading, would that prevent the menus from showing up?
Comment 29•26 years ago
|
||
I'm assuming by "wrapped" pages, you mean the addition of the sidebar and
titlebar. Maybe it would be possible to experiment with those and find out if
it's one thing in particular that's causing this problem to show up. Are those
added via SSI, a CGI script, or some other method? Are there URL's that will
bring the the top bar and side bar separately?
Comment 30•26 years ago
|
||
adding sspitzer to the cc list.
Comment 31•26 years ago
|
||
Seth: I loaded the mozilla.org pages from my apache server just fine. Is there
any way to trace netlib to see exactly what gets loaded and when?
bryner: Pages get "wrapped" with the title and side menu when you check in
files to the document tree. When you load mozilla.org pages, you are loading
straight html.
Comment 32•26 years ago
|
||
I need to get more sleep.
http://www.mozilla.org is Netscape-Enterprise/3.6 running on IRIX.
ignore my apache comments.
Comment 33•26 years ago
|
||
bash-2.00# uname -a
SunOS gila.mozilla.org 5.6 Generic_105181-04 sun4u sparc SUNW,Ultra-2
Right about the Enterprise Server part, though.
Comment 34•26 years ago
|
||
(thanks leaf, I telneted to mozilla.org not www.mozilla.org)
http://chupa/sspitzer/7417/mailnews/prefs-info.html
is being served by Netscape-Enterprise/3.6 on
SunOS chupacabra 5.5.1 Generic_103640-24 sun4u sparc SUNW,Ultra-1
so if file:// works and local (fast) web pages work, I'd say its time to debug
netlib and make sure we're getting the whole page from mozilla.org and the
connection is being closed.
Comment 35•26 years ago
|
||
Interestingly, this bug doesn't happen when the sidebar is collapsed (the one in
the apprunner browser window, not the fakie side table cell that's built into
mozilla pages).
Try it: when you see this problem in the browser, hit the flippy to collapse the
sidebar. Quit apprunner (with the windowmanager 'x' since there are no menus).
Start apprunner again. It comes up with the sidebar collapsed, and loads the
page perfectly well, and displays menus! Now click on the flippy to bring the
sidebar back; the sidebar doesn't really come back, but it sets internal state
so that if you quit and restart, apprunner starts with the sidebar, and sure
enough, now the bug is back!
Comment 36•26 years ago
|
||
Here is how you get a netlib trace:
setenv NSPR_LOG_MODULE NETLIB:5
setenv NSPR_LOG_FILE netlib.log
./apprunner
netlib.log has the log from netlib. Can one of you seeing the bug do that and
add an attachment.
Comment 37•26 years ago
|
||
I tried dp's suggested commands, since I'm seeing the bug right now, but it
didn't put a netlib.log into the current directory. In case it was a path
problem, I tried
setenv NSPR_LOG_FILE /tmp/netlib.log
but that didn't help, it didn't write anything to /tmp/netlib.log either.
I also tried PR_LOG_MODULE and PR_LOG_FILE, still no file. Any ideas?
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 38•26 years ago
|
||
Typo: NSPR_LOG_MODULES not NSPR_LOG_MODULE (sorry)
setenv NSPR_LOG_MODULES NETLIB:5
setenv NSPR_LOG_FILE netlib.log
Comment 39•26 years ago
|
||
I tried the corrected Netlib logging instructions and all I got was a 0-length
netlib.log. Does this require a debug build?
Comment 40•26 years ago
|
||
IMAP (via NSPR) logging in seamonkey used to require a debug build. bienvenu
fixed it...perhaps netlib logging would require a similar change.
Comment 41•26 years ago
|
||
Comment 42•26 years ago
|
||
Comment 43•26 years ago
|
||
dp- did you do the same actions on both runs? I noticed that the log from the
non-working run is almost twice as long as for the working run.
Comment 44•26 years ago
|
||
Ah, nevermind I think it's just because of the 1024[804f108]: on every line.
Comment 45•26 years ago
|
||
Brian, you are right, the bad run does have a lot more stuff. Dp said that might
have to do with reaching the 4 connection limit:
More than 4 cached connections. Deleteing one...
But actually, I see more of those messages in the good run.
Comment 46•26 years ago
|
||
It looks like you got the working run by turning off the sidebar. Can anyone
seem to get a working run WITH the sidebar?
Comment 47•26 years ago
|
||
Comment 48•26 years ago
|
||
Comment 49•26 years ago
|
||
Note that to create the above diff I made the mozilla paths the same and removed
the beginning of line headers, so what's shown is the real differences.
Comment 50•25 years ago
|
||
*** Bug 3291 has been marked as a duplicate of this bug. ***
Comment 51•25 years ago
|
||
Status: Still cant reproduce the bug reliably. Theory is that this looks server
and time of day dependent. Netlib logs look ok.
Suggestion: wait until necko lands.
Updated•25 years ago
|
Whiteboard: no progress towards reproducability in m7 -> moving to m8
Target Milestone: M7 → M8
Comment 52•25 years ago
|
||
I don't see how M7 can ship with this still happening.
Reporter | ||
Updated•25 years ago
|
Whiteboard: no progress towards reproducability in m7 -> moving to m8 → this is randomly reproduceable, we need a workaround for M7
Target Milestone: M8 → M7
Reporter | ||
Comment 53•25 years ago
|
||
Agreed, we can't ship M7 like this.
Moving back to M7, asking for a work-around.
Maybe a Linux-only work-around?
Updated•25 years ago
|
Assignee: dp → chofmann
Status: ASSIGNED → NEW
Comment 54•25 years ago
|
||
start page changes to http://www.browserwatch.com until we fix this.
I had to change mozilla/xpfe/browser/src/navigator.xul.
For M8, I'm going to write some javascript to get the value of the start up
page pref.
Something like:
var pref = Components.classes['component://netscape/preferences'];
if (pref) {
pref = pref.getService();
}
if (pref) {
pref = pref.QueryInterface(Components.interfaces.nsIPref);
}
if (pref) {
startuppage = pref.GetCharPref('startpage');
}
you get the idea.
Updated•25 years ago
|
Target Milestone: M7 → M8
Comment 55•25 years ago
|
||
using work around for m7. moving to m8.
Comment 56•25 years ago
|
||
dmose wisely point out that:
"just curious to know if anyone has checked with browserwatch.com to make
sure that they're ok with this. we've had problems in the past with
doing stuff that we thought was benign and causing people's sites to get
hammered, and they haven't been happy..."
can someone confirm that #7417 won't rear its ugly head if the start page is
http://www.netscape.com?
Comment 57•25 years ago
|
||
Could we possibly just make the start page about:blank or one of the built-in
samples? That would also immensely speed startup for those of us who are
testing something other than the default page. If the smoketests need a
complicated, slow startup page, they could specify -url (is there a way to do
this on mac?)
Reporter | ||
Updated•25 years ago
|
Target Milestone: M8 → M7
Reporter | ||
Comment 58•25 years ago
|
||
Back onto the M7 radar for URL confirmation.
Comment 59•25 years ago
|
||
when m8 opens up, I'll check in some changes to
mozilla/xpfe/browser/src/navigator.js
mozilla/modules/libpref/src/init/all.js
mozilla/xpfe/browser/src/navigator.xul
then, the start page will be determined by the int pref "browser.startup.page"
// 0 = blank, 1 = home (browser.startup.homepage), 2 = last, 3 = splash (browser
.startup.splash)
depending on that pref, we use about:blank, the value of the char pref
"browser.startup.homepage", the last visted page, or the value of the char pref
"browser.startup.splash"
all of this is done through js!
Comment 60•25 years ago
|
||
I've sent mail to the mozillazine.org owner asking if it's ok to switch to his
page... it's a bit more relevant to mozilla users than www.netscape.com, and it
loads relatively quickly.
Updated•25 years ago
|
Assignee: chofmann → leaf
Whiteboard: this is randomly reproduceable, we need a workaround for M7 → have workaround for m7, this is randomly reproduceable and ugly without it,
Updated•25 years ago
|
Assignee: leaf → warren
Target Milestone: M7 → M8
Comment 61•25 years ago
|
||
back to m8 and over to warren
Comment 62•25 years ago
|
||
www.pathfinder.com, which eventually redirects to
http://cgi.pathfinder.com/time, exhibits this same behavior on Linux.
Comment 63•25 years ago
|
||
Moving all Apprunner bugs past and present to Other component temporarily whilst
don and I set correct component. Apprunner component will be deleted/retired
shortly.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Target Milestone: M8 → M9
Comment 64•25 years ago
|
||
necko now lands in m9
Comment 65•25 years ago
|
||
*** Bug 9610 has been marked as a duplicate of this bug. ***
Comment 66•25 years ago
|
||
I have been noticing this too for a while...and i just wanted to add a few urls
that lead to the menu and resizing to be disabled. If you go to any of these
sites, you will no longer be able to use the menu or properly resize the window:
www.pathfinder.com
www.warnerbros.com
www.usatoday.com
www.mozilla.org
Comment 67•25 years ago
|
||
so does www.bild.de. (don't ask me how i knew that).
i'll try to figure out what these sites have in common.
Comment 68•25 years ago
|
||
well there is a mix of versions but they are all
enterprise servers and they are all http 1.1
grok /u/chofmann % telnet www.mozilla.org 80
Trying 207.200.73.41...
Connected to gila.mozilla.org.
HTTP/1.1 400 Bad Request
Server: Netscape-Enterprise/3.6
grok /u/chofmann % telnet www.warnerbros.com 80
Trying 204.140.6.16...
Connected to www.warnerbros.com.
HTTP/1.1 400 Bad Request
Server: Netscape-Enterprise/3.5.1C
grok /u/chofmann % telnet www.usatoday.com 80
Trying 206.251.19.72...
Connected to www.usatoday.com.
HTTP/1.1 400 Bad Request
Server: Netscape-Enterprise/3.6
----------------
its interesting to note that cnn is http 1.0 enterprise 2.0
grok /u/chofmann % telnet www.cnn.com 80
Trying 207.25.71.20...
Connected to cnn.com.
HTTP/1.0 400 Bad Request
Server: Netscape-Enterprise/2.01
and photnet is ms iis
rok /u/chofmann % telnet photo.com 80
Trying 206.31.52.194...
Connected to photo.com.
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/4.0
Comment 69•25 years ago
|
||
maybe a enterprise server bug that was broken in 3.x but
fixed in an enterprise service pack? www.uiu.edu is
on the working list and it shows 3.6 SP2
Trying 128.174.5.27...
Connected to spider.cso.uiuc.edu.
HTTP/1.1 400 Bad Request
Server: Netscape-Enterprise/3.6 SP2
Comment 70•25 years ago
|
||
Has anyone figured out yet whether this still happens in necko?
Comment 71•25 years ago
|
||
As far as I can see this doesn't happen with Necko. I changed the start page to
www.mozilla.org and I get working menus and working resizing. But since the
problem comes and goes some other people should try to verify it.
Reporter | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 72•25 years ago
|
||
I think this has fixed itself with the NECKO landing,
marking worksforme.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 73•25 years ago
|
||
verified worksforme...these problems have disappeared after the necko landing.
Whiteboard: have workaround for m7, this is randomly reproduceable and ugly without it, → [PDT+]have workaround for m7, this is randomly reproduceable and ugly without it,
Comment 74•25 years ago
|
||
Putting on [PDT]+ radar.
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•