Closed
Bug 524233
Opened 16 years ago
Closed 16 years ago
Opening a new tab after it has finished loading ends up with blank content within that tab
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(fennec1.0+)
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
fennec | 1.0+ | --- |
People
(Reporter: aakashd, Unassigned)
References
Details
(Whiteboard: [fennecb5testday])
Build Id:
Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.2b1pre) Gecko/20091023 Fennec/1.0a4pre
and
Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2b1pre) Gecko/20091023
Fennec/1.0b5pre
Steps to Reproduce:
1. Go to http://popuptest.com/
2. Run the Multi-Popup test
3. When the notification bar appears, click on show
4. Open up the tab sidebar and click on one of the newly created tabs
Actual Results:
The new tabs all have blank content, but their thumbnails show the content that should be shown in the content window
Expected Results:
The content window should show the contents of the popup
Reporter | ||
Updated•16 years ago
|
tracking-fennec: --- → ?
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Comment 2•16 years ago
|
||
unable to verify this bug with 20091106 1.9.2 nightly on my n810. I do this test and experience the exact bug that aakash reported initially.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter | ||
Updated•16 years ago
|
Severity: major → blocker
Summary: Showing popups ends up with blank content within the tab → Opening a new tab after it has finished loading ends up with blank content within that tab
Reporter | ||
Updated•16 years ago
|
Whiteboard: [fennecb5testday]
![]() |
||
Comment 3•16 years ago
|
||
With the 20091113 nightlies of 1.9.2 and trunk, if you
1. Ctrl-click a link to open it in a new tab;
2. wait for the page in the new tab to load completely(!);
3. switch to the new tab;
the new tab's content area will be blank.
Comment 4•16 years ago
|
||
The image for the tab bar will paint to match the new page, it's just the content that never paints correctly
Comment 5•16 years ago
|
||
The WIP fix for bug 526904 also fixes this problem for me on Win32 desktop.
Depends on: 526904
Updated•16 years ago
|
tracking-fennec: ? → 1.0+
![]() |
||
Comment 6•16 years ago
|
||
WFM on Linux i686 with
1.9.2 nightly 20091125[015206] Namoroka/3.6b5pre Fennec/1.0b6pre;
trunk nightly 20091125[013651] Namoroka/3.7a1pre Fennec/1.0b6pre.
Hooray!
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 7•16 years ago
|
||
moving this to verified with Aleksej's approval and a quick check on my side.
Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2b5pre) Gecko/20091130 Firefox/3.6b5pre Fennec/1.0b6pre
Status: RESOLVED → VERIFIED
Reporter | ||
Updated•16 years ago
|
Flags: in-litmus?
Reporter | ||
Updated•16 years ago
|
Flags: in-litmus? → in-litmus-
You need to log in
before you can comment on or make changes to this bug.
Description
•