progress bar goes beyond 100%

[hrj]

For some websites, the progress bar shown in status bar, while loading the page, goes beyond 100%.

[bogas04]

Do you know the reason for it ? A quick hack would be to set it around 99 if it exceeds 100

 this.setString((((value * 100) / max) > 100 ? 99.99 : (value * 100) / max) + "%");

[hrj]

@bogas04 I don't know the reason yet. But I don't want to use a quick hack for this.

[hrj]

The progress bar (and bug) is noticeable only when the internet speed is slow. I tried a bunch of websites just now, but darn, my internet is acting up fast at the moment :)

The ideal way to test it would be to intentionally add a delay to the response. It should be easy to take a small server script such as this and intentionally add a delay to the responses. Then load a web-page through that server, which contains many resources (images, CSS, scripts).

[bogas04]

I tried to read the complex code and finally reached here:

These lines in Platform_Core/org.lobobrowser.request.ClientletResponseImpl.java have value of pe.getProgress() greater than that of contentLength, for google.com on initial load.

        final MonitoredInputStream mis = new MonitoredInputStream(in);
        mis.evtProgress.addListener(new GenericEventListener() {
          public void processEvent(final EventObject event) {
            final InputProgressEvent pe = (InputProgressEvent) event;
            requestHandler.handleProgress(
              org.lobobrowser.ua.ProgressType.CONTENT_LOADING
              ,responseURL
              ,getLastRequestMethod()
              ,pe.getProgress()
              ,contentLength
             );
          }
        });

and the event seems to be fired by read(args) in Common/org.lobobrowser.util.MonitoredInputStream.java

  public int read(final byte[] arg0, final int arg1, final int arg2) throws IOException {
    final int numRead = this.delegate.read(arg0, arg1, arg2);
    if (numRead != -1) {
      this.progress += numRead;
      final long currentTime = System.currentTimeMillis();
      if ((currentTime - this.lastEvenPosted) > this.minProgressEventGap) {
        this.evtProgress.fireEvent(new InputProgressEvent(this, this.progress));
        this.lastEvenPosted = currentTime;
      }
    }

So my guess is that the logic of this.progress += numRead; might be flawed somewhere.

[hrj]

Our current analysis is:

This seems to happen for compressed content. The progress bar probably uses the content-length header sent by the server to estimate the number of bytes in the response. However, if the response is compressed, the actual number of bytes is higher, and this confuses the progress bar.

Solutions:

1. Consider only compressed length at all times. (Should be more reliable)
2. When dealing with compressed responses, use a binary state for progress. That is assume that the length of the response is 1; the number of bytes received will be 0 until the response is fully received.

Apart from that, the content-length header is not very reliable (we are trusting the server to send the right value). So whenever the actual response is larger than the estimated length, we can cap the byte count.