Closed
Bug 1091480
Opened 10 years ago
Closed 4 years ago
Unexpected behaviour of -moz-column-count
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: kaze.no.tania, Unassigned)
Details
Attachments
(5 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 Steps to reproduce: Firefox v33.x.x. We have detected a case in which property -moz-column-count does not work as expecetd. We can see an example in the attached HTML (Column.htm file) In that HTML, we have a div with fixed positioning and 30px gap in which we show some text horizontally in a column (as you can see, it has an horizontal scroll bar). By using jquery, we do an scrollleft of 245 px. We also have a text ("varius felis") with yellow background. The unexpected behaviour can be reproduced by clicking on the "Replace background text" button. That button replaces the marked text with a new one. The problem is that the horizontal scroll position is lost, we are positioned at the begining of the document and the horizontal visualization is completely lost (in fact, a vertical scroll appears). This does not seem to happen when -moz-column-count is set to 2. Column-2col.htm has the same example, but with 2 column visualization. When the button is clicked, the text is replaced, but the horizontal position is not lost and the horizontal scroll bar is kept. Actual results: Horizontal scroll positioning is lost when we made a change in the DOM when column count is 1. This does not happen when column count is 2. Expected results: The horizontal scroll positioning should have remained the same after the change in the DOM.
I got a regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d2a7a8ca1c7&tochange=582d4c67b3a7 Suspected: Scott Johnson — Bug 764567: Implement column-fill part of CSS3 multicol spec, now with regression fixes [r=roc]. Any idea, Scott?
Component: General → Layout
Flags: needinfo?(jaywir3)
Comment 4•10 years ago
|
||
(In reply to Loic from comment #3) > I got a regression range: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=9d2a7a8ca1c7&tochange=582d4c67b3a7 > > Suspected: > Scott Johnson — Bug 764567: Implement column-fill part of CSS3 multicol > spec, now with regression fixes [r=roc]. > > Any idea, Scott? Hm, it's possible that there is a bug in that code. The column set code is pretty complex. I'm not at a place where I can debug this at the moment, but I'll try to look into it as soon as I have a chance.
Comment 5•10 years ago
|
||
So, with the following release build: > { > "application": { > "name": "Firefox", > "version": "32.0.3", > "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:32.0) Gecko/20100101 Firefox/32.0", > } I'm not seeing the issue as presented. In fact, the 'Change background text' button doesn't do anything for me on either document. Since bug 764567 went into FF 17 and is in core layout code, it seems like this would be present in all versions 17-33. (i.e. It doesn't seem like it would be platform-specific)
Flags: needinfo?(jaywir3)
(In reply to Scott Johnson (:jwir3) from comment #5) > So, with the following release build: > > > { > > "application": { > > "name": "Firefox", > > "version": "32.0.3", > > "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:32.0) Gecko/20100101 Firefox/32.0", > > } > > I'm not seeing the issue as presented. In fact, the 'Change background text' > button doesn't do anything for me on either document. Because the testcase loads ressources from a different domain (probably the jQuery lib), you need to disable CSP blocking with the placeholder in the location bar.
Comment 8•10 years ago
|
||
(In reply to Loic from comment #6) > Because the testcase loads ressources from a different domain (probably the > jQuery lib), you need to disable CSP blocking with the placeholder in the > location bar. Gotcha. I'm seeing it now.
Hello, I beg your pardon, but is it possible that you tell us any news on this issue? We can provide you more info about it if you need it. You mentioned that there could be an issue with our styles, as it seemed the column config was a bit complicated. Can it be our mistake, then? Thank you so much for your time.
Updated•8 years ago
|
Flags: needinfo?(jaywir3)
Comment 11•4 years ago
|
||
Ran across this bug today. I updated the testcase to have unprefixed column styling; with that, and downloading & running the testcase locally (so that the jquery cross-origin library-script load succeeds), I get "expected results" here, I think. When I click the button, the highlighted text changes & the scroll position isn't lost.
Updated•4 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•