291406 - Statusbar not showing progress.

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Eiichi]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050421 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050421 Camino/0.8+

In 2005-04-21 NB status dialog box in the status bar doesn't show correct
transferring status.
Is this concerned with attachment 181364 [details] [diff] [review] landed on 2005-04-20?

Reproducible: Always

Steps to Reproduce:

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #0)

> In 2005-04-21 NB status dialog box in the status bar doesn't show correct
> transferring status.

In what way?  I'm not noticing any difference, but I'm not sure what I'm
supposed to be looking for.

Comment 2

[Jasper]

I can confrim that in the 20052104 NB the status bar isn't showing any progress
like it did before. 

Just load a page and look at the bar, it will show the diagonal stripes and the
go to the normal mode where it just stays filled for only one or tewo pixels
while it should fill gradually. 

Comment 3

[Wevah (Nate Weaver)]

Hmm, yes indeed this is the case.

Comment 4

[Mike Pinkerton (not reading bugmail)]

hmmmm. what was that other bug? can someone cc the author of that patch on this bug?

Comment 5

[Eiichi]

CC: Mark Mentovai
the author of attachment 181364 [details] [diff] [review] [Bug 288585]

Comment 6

[Mike Pinkerton (not reading bugmail)]

*** Bug 291490 has been marked as a duplicate of this bug. ***

Comment 7

[Mike Pinkerton (not reading bugmail)]

upping priority. mark, any ideas? prolly just an api mismatch.

Comment 8

[Mike Pinkerton (not reading bugmail)]

there appeared to be nothing wrong with the patch, but when I was debugging it,
I noticed that as soon as we bridged from c++ to the obj-c browserWrapper, the
long long parameters became garbage. All I can guess is that there's a compiler
bug with gcc 3.3 and the 10.2 sdk and long longs. 

As a workaround, i separated the 32bit and 64bit progress apis on the browser
wrapper. if the page loading progress ever starts using the 64bit api, we'll
have to look into this again, but for now, the bug is fixed.

Comment 9

[Mike Pinkerton (not reading bugmail)]

also, fwiw, using the 64bit progress apis for browsing gave us a 60ms hit on the
pageload tests. backing those out and going back to the 32bit ones brought us
back to normal. yikes!!!

Comment 10

[Mark Mentovai]

Attachment: more work

Sorry about this.  Pink, how were the long longs mashed once they were in
ObjC-land?  I am seeing exactly the same results whether
CHBrowserListener/OnProgressChange calls BrowserWrapper/onProgressChange
directly or calls into onProgressChange64 via OnProgressChange64.  That is to
say, the longs are getting blown up into long longs properly, and the progress
thermometer still works.  (I didn't run pageload speed tests, though.)

I did have to apply the attached patch.  The only other change I make to test
the 64s is in camino/src/embedding/CHBrowserListener.mm, where in
OnProgressChange I make a call straight into OnProgressChange64.

I want to get this squared away now, even if Camino continues to use the 32-bit
APIs for the browser window.  Reopen if necessary?

Comment 11

[Mike Pinkerton (not reading bugmail)]

the first param looked like it was getting duplicated, eg, if it was 0x0175, it
was being passed as:

0x00000175 00000175

and the second param was just total garbage but some obscenely huge number. so
you'd end up dividing one sorta big number by an HUGE number, getting the result
of about .15, and that was always what the progress meter would show, so it
would never finish.

i'm curious if it's the difference between being on a G4 vs a G5. I was
debugging it on a G4 laptop. you say it works fine for you all the time?

Comment 12

[Mark Mentovai]

Attachment: Debugging

That almost sounds like an ABI problem to me, as if the caller was passing
things as 32 bits but the receiver was interpreting them as 64.

The attachment shows a step through a load of www.cnn.com.  I don't see any
problems in any of the conversions from 32 to 64 bits.

I'm working on a PowerBook G4 also.

The closest thing I see to the problem is when I look at the parameter areas in
a stack dump, but that doesn't count for much because I only see it in the
shadow area for the first 8 words, the actual values are passed in registers
and there's no guarantee they'll be on the stack when I look for them.	The
area past the first 8 words looks fine, so there's no reason to believe that
the registers are being filled with garbage.

Of course, all of this testing is with your separation of 32 and 64 bits and
the other tiny modifications in attachment 181708 [details] [diff] [review], so that may have changed
things since my initial patch.