2.0.0.12 Update breaks scrolling for dynamic content creation using tabs to display different trees.

RESOLVED FIXED

Status

()

--
major
RESOLVED FIXED
11 years ago
3 months ago

People

(Reporter: stuart.dodd, Unassigned)

Tracking

({regression, testcase})

1.8 Branch
regression, testcase
Points:
---
Bug Flags:
blocking1.8.1.13 -
blocking1.8.1.15 -
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

103.61 KB, application/x-zip-compressed
Details
637 bytes, text/html
Details
732 bytes, text/html
Details
(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

We are using JavaScript to dynamically generate 3 trees ans tab between them.

after doing an update to 2.0.0.12 our tabbing looks like the trees are going missing, the issue is actually that the scroll location of the new dynamic content thinks it is at 0 but it isn't and scrollTo / scroll does not scroll the new content to the top. When returning to the initial tree the scrollbars do not reset to the current location in the dynamic document.

This used to work in previous versions of firefox and has been introduced in the new release.

Reproducible: Always

Steps to Reproduce:
1. create a frameset
2. in one of the frames create a tree that is larger than the frame
3. create a JS tree to replace the new one that is only 2 elements high
4. Create a link to replace the content of the frame with the JS content
   Use frame.document.open(), frame.document.write(htm), frame.document.close()
5. The new page text appears to not show
6. scroll up with the mouse wheel to see the new content
7. create another link that replaces the original tree and follow it after going to the replaced content
8. This reproduces the offset scrollbars.
Actual Results:  
Text off the top of the target area

Scrollbars offset

Expected Results:  
Text shown in viewable area.

scrollbars at aprropriate locations.

This has broken existing functionality for our web application.
Can you please attach a minimal testcase using the 'Add an attachment' link? Thanks!
Keywords: regression
Version: unspecified → 2.0 Branch

Comment 2

11 years ago
Can you also just make sure it works in safe mode with all extensions and themes disabled?  A number of extensions edit content and were updated recently and may have affected your web application.

http://support.mozilla.com/kb/Safe+Mode for instructions on how to get into safe mode.

Keywords: qawanted
Whiteboard: [needs-testcase]
(Reporter)

Comment 3

11 years ago
Created attachment 302783 [details]
page dump of our WebApp

Instructions:

Extract the zip file and open mainpage.htm

Click Browse control : This is what should appear
Click Master Tree: Scroll down and focus on a link low in the tree
Click Browse Control : Content has disappeared

If you scroll up the content is there.

Safe mode makes no difference.
(Reporter)

Updated

11 years ago
Whiteboard: [needs-testcase] → [testcase-provided]
Flags: blocking1.8.1.13?
Keywords: testcase
Whiteboard: [testcase-provided]
Attachment #302783 - Attachment mime type: application/x-zip-compressed → application/java-archive
With the attached example I see the described behavior going back to at least Firefox 1.5 -- do you have a better example that shows the difference you're seeing between Firefox 2.0.0.11 and Firefox 2.0.0.12?
clearing blocking request. If this is confirmed and truly a recent regression you can re-request blocking.
Flags: blocking1.8.1.13?
(Reporter)

Comment 6

11 years ago
The Issue does occur as suggested above between versions 2.0.0.11 and 2.0.0.12 however the example i sent you does not reflect the issue correctly.

I'll put together a better example for you and make sure it works as the bug suggests. between the versions.

Hope to have something by the end of Friday all being well.
(Reporter)

Comment 7

11 years ago
Created attachment 307005 [details]
reworked example

This is an updated example that works every time.

1. Open the page
2. Click Master Tree to display the tree
3. click on a link to focus the tree so the scroll bar is towards the bottom
4. click browse control

you scroll up with the mouse wheel to see the 2nd tree which should be visible.
Attachment #302783 - Attachment is obsolete: true
(Reporter)

Updated

11 years ago
Summary: 10.0.0.12 Update breaks scrolling for dynamic content creation using tabs to display different trees. → 2.0.0.12 Update breaks scrolling for dynamic content creation using tabs to display different trees.
(Reporter)

Updated

11 years ago
Flags: blocking1.8.1.14?
Flags: blocking1.8.1.13?
1.8.1.13 is basically done. This won't block that release.
Flags: blocking1.8.1.13? → blocking1.8.1.13-
(Reporter)

Comment 9

11 years ago
This has skipped 2 releases now so I've had to upgrade the severity from major.

This makes our application look and behave in a bad way and this was only introduced in 2.0.0.12 and has followed through 2.0.0.13 and 2.0.0.14.

Can we have a solid ETA on when this will be resolved ?
Severity: major → critical
2.0.0.14 was a firedrill release where we released for one specific fix.

This bug isn't "critical" by the definitions we use of bugs (crashes or hangs). Someone with more knowledge than I needs to look at your example and confirm this bug otherwise there's no way we can have a solid ETA for a resolution.
Severity: critical → major
(In reply to comment #9)
> This has skipped 2 releases now so I've had to upgrade the severity from major.
> 
> Can we have a solid ETA on when this will be resolved ?

It's really off the radar as an "unconfirmed" bug. Can you work with community support/QA folks to get this confirmed? http://www.mozilla.org/support/#community 

All right. I've confirmed this on both Windows XP and OS X 10.5.2. (This isn't Windows specific so I'll update the bug.) In 2.0.0.11, the left pane isn't empty after the final step.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Is there any way to get a reduced testcase? there's a lot going on in here.

qawanted: can we get a regression range down to a nightly build? that would help us find the regressing bug.
Flags: wanted1.8.1.x+
Flags: blocking1.8.0.15?
Keywords: qawanted
Martijn, for that last testcase is the expected behavior that the scrollbar is positioned at the top and the text is visible?  Or is it that the scrollbar is positioned at the bottom after the second click?
Sorry, I should have said, what I see. After doing the steps to reproduce in the testcase, I see the scrollbar that is positioned at the top, but the text is not visible. But scrolling upwards with the mousewheel, suddenly positions the scrollbar to the bottom and then scrolls upwards (because of the mousewheel action).
Right.  That doesn't really answer my question from comment 16...  What did we use to do before this regressed?
Sorry, the testcase I attached is actually also busted for older branch builds.
(althought it's probably still related to what is busted for the url in question)
Created attachment 317527 [details]
testcase2

Ok, this testcase reflects what regressed, I think. This is basically the same as the first testcase, but this has '<link href="data:text/css;charset=utf-8,.rubbish%20%7B%7D%0A" rel="stylesheet" type="text/css">' added. This regressed with the regression range mentioned in comment 14.
That sounds like we just have a view system bug that was hidden by the presence of the stylesheet's view update batch or something...

roc, any idea what's up with that?

Looking at the view dumps on branch, right after the second button click we have:

0xb0a32180 (widget=0xb0ab2878[4] z=0 pos={0,0,4200,2100}) {0,0,4200,2100} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a8fee4 <
  0xb0a8d6e0 {0,0,4200,2100} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a900c4 <
    0xb0a8d248 (widget=0xb0a78618[2] z=0 pos={0,0,3990,2100}) {0,0,3990,2100} z=0 vis=1 opc=1.000 tran=1 clientData=(nil) <
      0xb0a788e0 {0,-1862,3990,3976} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a8ff78 <
      >
    >
    0xb0a87fe8 {3990,0,210,2100} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a77be4 <
      0xb0a88070 {28,168,154,1750} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a77f00 <
      >
    >
    0xafd11c88 {0,2100,3990,0} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a9043c <
      0xb0a8d350 {168,28,3654,154} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a9086c <
      >
    >
  >
>

If I then scroll down one notch (which makes the text reappear) and scroll back up to the top, the view dump looks like:

0xb0a32180 (widget=0xb0ab2878[4] z=0 pos={0,0,4200,2100}) {0,0,4200,2100} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a8fee4 <
  0xb0a8d6e0 {0,0,4200,2100} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a900c4 <
    0xb0a8d248 (widget=0xb0a78618[2] z=0 pos={0,0,3990,2100}) {0,0,3990,2100} z=0 vis=1 opc=1.000 tran=1 clientData=(nil) <
      0xb0a788e0 {0,0,3990,3976} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a8ff78 <
      >
    >
    0xb0a87fe8 {3990,0,210,2100} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a77be4 <
      0xb0a88070 {28,168,154,1750} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a77f00 <
      >
    >
    0xafd11c88 {0,2100,3990,0} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a9043c <
      0xb0a8d350 {168,28,3654,154} z=0 vis=1 opc=1.000 tran=1 clientData=0xb0a9086c <
      >
    >
  >
>

Note the difference in the y-position of 0xb0a788e0.  So it looks like doing the document.open/write/close somehow confuses the scrollframe so that the scrollbar state no longer matches the view position...
Component: General → Layout: View Rendering
Product: Firefox → Core
QA Contact: general → layout.view-rendering
Version: 2.0 Branch → 1.8 Branch
Blocking on the web-compat regression
Flags: blocking1.8.1.15? → blocking1.8.1.15+
Well, it is already broken on branch, just for this particular case it happened to work correctly.
Although it's unfortunate things got slightly worse, fixing this correctly and safely is beyond what we can squeeze into a branch stability release.
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.15-
Flags: blocking1.8.1.15+
Flags: blocking1.8.0.15?
This was fixed by some combination of bug 319123 and bug 321781.  At least on then-trunk (now 1.9.0 branch).
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
(Assignee)

Updated

3 months ago
Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.