[Mono-bugs] [Bug 450479] New: WebBrowser. ProgressChanged event values will cause errors on apps consistent with MSFT

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=450479


           Summary: WebBrowser.ProgressChanged event values will cause
                    errors on apps consistent with MSFT
           Product: Mono: Class Libraries
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: Windows.Forms
        AssignedTo: avidigal at novell.com
        ReportedBy: andyhume32 at yahoo.co.uk
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---


The MSDN documentation on the WebBrowserProgressChangedEventArgs properties (at
least in the most up-to-date version) says:
* CurrentProgress -- "The number of bytes that have been loaded or -1 to
indicate that the download has completed."
* MaximumProgress -- "The total number of bytes to be loaded."

That matches the behaviour seen from the MSFT implementation (with caveats, see
below).

Mono doesn't follow this.
1. It doesn't report 'current' as -1 to signal completion.
2. It reports -1 for 'maximum' when it doesn't know the download size (e.g.
when no Content-Length header).
3. It reports 'current' greater than 'maximum' when it has a misconception of
the download size.

Thus, problems will occur when using an event handler like the following:
   if (e.CurrentProgress == -1)
       progressBar.Visible = false;
   else {
       progressBar.Maximum = e.MaximumProgress; // (Must resize the bar first)
       progressBar.Maximum = e.CurrentProgress;
       progressBar.Visible = true;
   }

Thus:
1. The ProgressBar will stay visible after the page has completed.
2. Unhandled ArgumentException from ProgressBar.
3. Unhandled ArgumentException from ProgressBar.

Due to 2 and 3, crash. :-(

I guess the current event is just reporting the native browser component's
event and values.  Apparently they'll have to be massaged to suit. :-(

Needing assert(cur <= max), assert(max >= 0), assert(cur==-1 at completion).


Note, that MSFT's WebBrowser doesn't report the precise byte sizes -- for
'maximum' it reports instead 10000, or 100000 etc, and 'current' is modified
similarly, to 100, 250, etc etc.

Note that MSFT also produces an event with 0/0 after DocumentCompleted, and a
cur=max event just before DocumentCompleted.  I think that those events need
not be duplicated however.  Or maybe some apps do use them... 


Finally however, even if Mono matches all that behaviour, then problems may
occur when the app is run on Mono.  That's because in MSFT the control
apparently swallows all exceptions in event handlers, so any faults in the
app's event handler will only be seen on Mono. :-(


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.