Open Bug 1223067 Opened 9 years ago Updated 2 years ago

Pasting long rules in Ruleview can move all rules to the left, breaking the UI

Categories

(DevTools :: Inspector: Rules, defect, P3)

defect

Tracking

(firefox45 affected)

REOPENED
Tracking Status
firefox45 --- affected

People

(Reporter: arni2033, Unassigned)

References

Details

Attachments

(1 file)

STR: (Win7_64, Nightly 45, 32bit, ID 20151108030417, new profile) 1. Open new tab 2. Open devtools -> Inspector, select <body> in markup-view, open ruleview tab in sidebar 3. Click "element { }" box to start creating new rule 4. Paste there (Ctrl+V) the following string: > background: transparent url("https://mozorg.cdn.mozilla.net/media/img/firefox/firstrun/logo-nightly.cafba4805593.png#its_possible_that_web_pages_use_long_urls_and_dont_forget_about_data_urls") no-repeat scroll 50% 30px; Result: [see screenshot] all rules are moved to the left, UI doesn't look good Expectations: Other rules shouldn't move anywhere = should be stationary
Also it breaks with another valid rule: >font: normal small-caps 12px/14px 'Fira Sans','Open Sans','Helvetica Neue',Arial,Helvetica,sans-serif;
We need multi-line editors in the rule-view, this would also be super useful when editing (not inserting) long values like linear-gradients or multiple background images for instance.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Has STR: --- → yes
Component: Developer Tools: Inspector → Developer Tools: CSS Rules Inspector
Seriously, it's better to block bugs in such cases. This bug still happens. Actually, it became worse. Now it's reproducible with the following rule: > font: normal small-caps 12px/14px 'Fira Sans', 'Open Sans', 'Helvetica Neue', Arial, Helvetica, sans-serif;
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Thanks for re-opening. While closing as duplicate is often very useful (a lot of duplicate bugs get filed all the time), I agree that in this case it shouldn't have been closed because the multi-line editor is used only when editing a value, not when pasting a new one like in comment 0. The problem here is that once you pasted, the input field stays active and, because of the long string, the whole UI is scrolled right. Pressing ENTER to commit the new declaration does resolve the issue because then the value wraps correctly. I think we should do one of these: - find a CSS fix to make the various separator lines extend to the very end of the container, so the UI doesn't look broken - or switch immediately to a multi-line editor to force wrapping - or (and this is what I think we should really do): immediately commit the new declaration. We know the pasted string contains name:value so most probably what the user wants to do is insert a new declaration, so staying in edit mode isn't useful.
Priority: -- → P3
Product: Firefox → DevTools
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: