WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
49803
Setting inline style to float:right from JS has no effect on element with text-align:right
https://bugs.webkit.org/show_bug.cgi?id=49803
Summary
Setting inline style to float:right from JS has no effect on element with tex...
Jonathan
Reported
2010-11-19 06:54:56 PST
Please refer to the attached example page when inspecting this bug. I've mocked up this example based on a bug report that we received from one of our customers. Our company sells a CSS IDE that allows users to edit page CSS and see their changes in different browsers in real time. To accomplish this, we use JavaScript to modify the CSS. In testing, we have found that when the float:right property of an element is changed via JavaScript, the rendering engine does not re-draw the page. If the page is refreshed, everything is redrawn as expected. Please open bug.html in the attached zip file and click on the 'Toggle the float' link. On the click event, a chunk of jQuery in the head of the file adds a float:right property to the DIV.tit element. Under both Chrome and Safari (webkit browsers), this JavaScript does not cause the page to redraw. Under both IE8 and FF3.6.8, the page does indeed redraw as expected. You can find out more about the issue in this thread on our support forum:
http://service.skybound.ca/discussions/problems/2136-float-is-not-shown-until-refreshed
Feel free to contact me with any more questions about my implementation or this problem. Thanks, Jonathan Fritz Skybound Software
Attachments
Example code
(26.56 KB, application/x-zip-compressed)
2010-11-19 06:55 PST
,
Jonathan
no flags
Details
Example code simplified
(26.46 KB, application/x-zip-compressed)
2010-11-19 10:40 PST
,
Jonathan
no flags
Details
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Jonathan
Comment 1
2010-11-19 06:55:25 PST
Created
attachment 74384
[details]
Example code
Alexey Proskuryakov
Comment 2
2010-11-19 10:18:30 PST
I can reproduce this in ToT, and also when modifying the style in Web Inspector. Changing the source to include float:right produces expected result, so this is indeed an issue with dynamic adding of this style property. I've tried adding float:right to some elements on other pages, and it worked, so this is something triggered by other CSS in this example.
Jonathan
Comment 3
2010-11-19 10:39:40 PST
Alexey, If I understand you correctly, your theory is that the problem lies with some other aspect of the page or CSS, because you can't seem to reproduce the issue on a different web page. To counter this, I have greatly reduced the complexity of both the markup and the CSS involved in this example. The original example was overly complicated because we were using a CSS-based method to clearfix the header. I've removed a great deal of that complexity, and boiled the example down to the bare minimum of code. Hopefully this helps you to pinpoint the issue. Jonathan Fritz Skybound Software
Jonathan
Comment 4
2010-11-19 10:40:40 PST
Created
attachment 74402
[details]
Example code simplified Wanted to reduce the complexity of the original example code.
Alexey Proskuryakov
Comment 5
2010-11-19 11:44:01 PST
Thanks for the further reduction, it's helpful indeed! Removing text-align makes dynamic changes to float work in this test.
Jonathan
Comment 6
2010-11-19 12:59:21 PST
Alexey, Removing the text-align:right property does indeed make dynamic changes work, but it still doesn't result in the expected behaviour. In my case, once I remove the text-align:right property, applying the float:right property via JavaScript causes the H1 to move to the right of the DIV.header element, but not to the top-right corner beside the image where I would expect it to go. So it looks like the DOM is responding to JavaScript now, but as far as I'm concerned, not correctly. Would you agree? Jonathan Fritz Skybound Software
Jonathan
Comment 7
2010-11-26 05:53:13 PST
Hey Guys, Has there been any progress on this bug? I'm happy to answer any questions or provide any additional information that you might need to proceed. Thanks, Jonathan Fritz Skybound Software
Brent Fulgham
Comment 8
2022-07-12 13:57:28 PDT
Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug