Bug 8117 - Browser doesn't show progress indicator when user selects url from urlbar completion list
: Browser doesn't show progress indicator when user selects url from urlbar com...
Status: RESOLVED FIXED
Product: Browser
User interface
: 5.0/(2.2009.51-1)
: All Maemo
: Unspecified normal with 1 vote (vote)
: 5.0/(10.2010.19-1)
Assigned To: Nagineni Sudarsana Babu
: browser-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2010-01-16 13:10 UTC by Casper van Donderen
Modified: 2010-03-15 20:51 UTC (History)
4 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Casper van Donderen (reporter) 2010-01-16 13:10:05 UTC
SOFTWARE VERSION:
2.2009.51-1

EXACT STEPS LEADING TO PROBLEM: 
1. Open browser and start typing an URL.
2. Select a previously opened URL from the pop-up list (not observed when
typing a new URL, only when selecting one from the list)
3. The page correctly loads without giving progress feedback.

EXPECTED OUTCOME:
The blue progress indicator starts to fill up.

ACTUAL OUTCOME:
The address bar does gain the 'cross'-button, but no progress is shown. No
progress is shown while the browser stays active. After closing and immediately
retarting the browser the progress bar works. If the browser was closed for
more than a few minutes the problem with the progress bar is there again.

REPRODUCIBILITY:
When using a previously opened page from the pop-up list in the browser start
screen about 5/10.

EXTRA SOFTWARE INSTALLED:
(seems not relevant:)
OGG support
Catorise

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2a1pre)
Gecko/20091127 Firefox/3.5 Maemo Browser 1.5.6 RX-51 N900
Comment 1 tuukka.tolvanen nokia 2010-01-16 15:39:35 UTC
Couldn't reproduce in internal build near 2009w53 -- this could use more exact
steps, as in, which url is used, exactly which browser-related windows are open
at which point, is the display allowed to blank at some point, timings in
general
Comment 2 Casper van Donderen (reporter) 2010-01-16 17:02:18 UTC
For me it happens with multiple websites. observed with:
bugs.maemo.org
maemo.org
last.fm

I do not know if it has anything to do with my update process:
- Install 44-1 with NSU 1.8.10en
- The next day 51-1 was available.
- Try updating using NSU. that stayed on 'time remaining: 1 second' for two
hours.
- I decided to unplug the N900 which caused the device to not be able to boot
anymore.
- Install 51-1 using the flasher.exe under Windows XP SP3.
Comment 3 timeless 2010-01-16 18:40:48 UTC
wow
Comment 4 Andre Klapper maemo.org 2010-01-20 15:50:36 UTC
I cannot reproduce this currently with the internal version 2010.03-8.

(In reply to comment #3)
> wow

timeless, how may I interpret this? ;-)
Comment 5 timeless 2010-01-20 21:48:49 UTC
oh, i was testing w/ 51-1, and found it an amusing failure. it isn't meant to
be a comment that it would still be broken in future versions.

If you and tuukka agree that it's fixed, please resolve it :).
Comment 6 Andre Klapper maemo.org 2010-02-03 14:22:09 UTC
CLosing as FIXED.

A future public update will include the fix. (This is not always already the
next public update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 7 Andre Klapper maemo.org 2010-03-15 20:51:47 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).