Bug 5684 – History images do not match actual URLs under them

Bug 5684 - (int-136461) History images do not match actual URLs under them

(int-136461)
Summary:	History images do not match actual URLs under them

Status:	RESOLVED FIXED

Product:	Browser
Component:	User interface
Version:	5.0/(2.2009.51-1)
Platform:	All Linux

Importance:	Low normal with 5 votes (vote)
Target Milestone:	5.0/(10.2010.19-1)
Assigned To:	unassigned
QA Contact:	browser-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2009-10-21 21:39 UTC by Attila Csipa
Modified:	2010-06-03 13:39 UTC (History)
CC List:	6 users (show)

See Also:

Attachments
This bug on PR1.2 (51.65 KB, image/png) 2010-05-28 10:29 UTC, PeteC	Details
Add an attachment (proposed patch, testcase, etc.)

Note

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

Description Attila Csipa (reporter) nokia

2009-10-21 21:39:47 UTC

SOFTWARE VERSION:
Maemo 5, 1.2009.41-10

STEPS TO REPRODUCE THE PROBLEM:
I was browsing talk.maemo.org, tried to report a bug, typed manually
bugs.maemo.org into the address bar, clicked on log-in, entered the wrong
password by accident, and hit the back button to reenter.

EXPECTED OUTCOME:
Go back to the login screen, as is displayed on the image

ACTUAL OUTCOME:
Clicking on the image took be back to talk.maemo.org, the URL that is actually
written under the image, see
http://web.atombiztos.hu/Screenshot-20091021-195515.png

REPRODUCIBILITY:
sometimes

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14)
Gecko/2009090217 Ubuntu/9.04 (jaunty) Firefox/3.0.14

Comment 1 Andre Klapper maemo.org

2009-10-22 12:11:50 UTC

Thanks for reporting this.

Confirming.

Comment 2 PeteC 2010-01-05 10:57:31 UTC

Confirmed in 42-11 also.

This happens more often than not for me, making swipe-history too confusing to
be useful.

Comment 3 Per 2010-01-11 12:06:12 UTC

Confirmed here also.
Here's an example using google.com:
http://farm3.static.flickr.com/2630/4173617133_6012766336_o.png

Comment 4 Andre Klapper maemo.org

2010-01-13 18:16:56 UTC

This has been fixed in package
tablet-browser-controls 1.6.5.6-1+0m5
tablet-browser-view 2.2.4.2-1+0m5
which is part of the internal build version
2010.01-7
(Note: 2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version 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 5 Andre Klapper maemo.org

2010-02-16 14:06:13 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 3.2010.02-8 (also called "PR1.1.1"
sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

Comment 6 tuukka.tolvanen nokia

2010-02-17 01:19:17 UTC

...also 10.* stuff :)

Comment 7 Dave Love 2010-02-27 22:14:27 UTC

(In reply to comment #5)
> The problem reported here should be fixed in the update released today for
> public: The Maemo5 update version 3.2010.02-8 (also called "PR1.1.1"

It seems not to be fully fixed.  With 1.1.1, I sometimes see a history item
image that is either black or has the top of a page later in the history
at the top, i.e. the image is correct at the bottom for the relevant URL,
but mixed with the wrong one at the top (around the top half).

Is a screenshot helpful next time it happens?

Comment 8 tuukka.tolvanen nokia

2010-02-28 18:22:20 UTC

To clarify comment 6, the fix is actually not on the 3.* branch (currently
available update) but in 10.2010.01 (a future update). As such, no screenshots
needed until that's released.

Comment 9 PeteC 2010-05-28 10:29:59 UTC

Created an attachment (id=2763) [details]
This bug on PR1.2

Bug confirmed on PR1.2, please re-open & update version field.

Comment 10 PeteC 2010-06-03 10:50:12 UTC

Should I create a new report?

Comment 11 Andre Klapper maemo.org

2010-06-03 13:39:05 UTC

PeteC: Yes, please (looks like a different code bug with exactly the same
visual output)