Closed Bug 1386222 Opened 7 years ago Closed 7 years ago

Text in URL/location/address bar is garbled/overlapping/corrupted/not rendered correctly

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Version:
56 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla56
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- unaffected
firefox56 --- verified

People

(Reporter: ajfhajf, Assigned: ehsan.akhgari)

References

Details

(Keywords: regression, steps-wanted)

Attachments

(2 files)

bug.png
5.34 KB, image/png
Details
Ensure that we always respect the undo/redo transaction history when modifying the <xul:textbox>.value dynamically through script
5.98 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
Attached image bug.png —
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170801100311 Steps to reproduce: Create new profile, enable menu bar, open new tab, go to (menu bar) Bookmarks - Planet Mozilla Actual results: Text in the url bar is not rendered correctly, it looks like there are two URLs one on top of the other. Screenshot attached Expected results: Just one URL that is readable
Setting to NEW confirming - all tabs that are open are corrupted...
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
OS: Unspecified → Windows 10
I've reproduced this bug on Windows 8.1 x64.
Component: Untriaged → Location Bar
Hardware: Unspecified → All
OS: Windows → All
Per bug #1386227 Comment #3 (In reply to Pascal Chevrel:pascalc from bug #1386227 Comment #3) > Last good revision: fa81cd2510dbadd71d657258c7e76de6d74775cc > First bad revision: 3377c3b7a86da2a6bcd8644b7cd4805fc2bfa22e > > Pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=fa81cd2510dbadd71d657258c7e76de6d74775cc&tochange=3377 > c3b7a86da2a6bcd8644b7cd4805fc2bfa22e > > Ehsan, it seems one of your recent patches caused this regression, could you > check please? Thanks
status-firefox-esr52: affected → unaffected
Flags: needinfo?(ehsan)
A more accurate regression range would be helpful.
Flags: needinfo?(ehsan)
(In reply to ajfhajf from comment #0) > Create new profile, enable menu bar, open new tab, go to (menu bar) > Bookmarks - Planet Mozilla I tried to reproduce, but there isn't any link called Planet Mozilla under bookmarks. And I can't reproduce using any other links.
Blocks: 1385525
Keywords: regressionwindow-wanted
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #9) > (In reply to :Ehsan Akhgari (needinfo please, extremely long backlog) from > comment #7) > > A more accurate regression range would be helpful. > > It's in Comment #6 > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=fa81cd2510dbadd71d657258c7e76de6d74775cc&tochange=3377 > c3b7a86da2a6bcd8644b7cd4805fc2bfa22e Oh, sorry, didn't see that! Then this is almost certainly caused by bug 1385525. I just need someone to tell me how to reproduce it now. :-)
Keywords: steps-wanted
STR 1. Open https://www.mozilla.org/en-US/firefox/nightly/firstrun/ 2. Open a new tab (click new tab button) 3. Alt > Bookmarks > then open "Planet Mozilla"
Component: Location Bar → Editor
Product: Firefox → Core
Oh of course, that makes sense. I can write a fix based on that description, but I'd still like to try to reproduce this so that I can verify the fix... :/
OK, finally managed to reproduce! The key to reproducing this is to use the keyboard to activate the menu item it seems. This is the JS stack leading to the .value setter call on our input element: (gdb) js 0 set_value(val = "https://planet.mozilla.org") ["chrome://global/content/bindings/autocomplete.xml":328] this = [object XULElement] 1 URLBarSetURI(aURI = [xpconnect wrapped nsIURI @ 0x7fffb745d460 (native @ 0x7fff9f25ac08)]) ["chrome://browser/content/browser.js":2780] this = [object ChromeWindow] 2 onLocationChange(aWebProgress = [xpconnect wrapped nsIWebProgress @ 0x7fffb69d7860 (native @ 0x7fffb5defd60)], aRequest = [xpconnect wrapped nsIRequest @ 0x7fffb745d400 (native @ 0x7fffb69cec40)], aLocationURI = [xpconnect wrapped nsIURI @ 0x7fffb745d460 (native @ 0x7fff9f25ac08)], aFlags = 0) ["chrome://browser/content/browser.js":4728] this = [object Object] 3 callListeners(listeners = [object Object], args = [xpconnect wrapped nsIWebProgress @ 0x7fffb69d7860 (native @ 0x7fffb5defd60)],[xpconnect wrapped nsIRequest @ 0x7fffb745d400 (native @ 0x7fffb69cec40)],[xpconnect wrapped nsIURI @ 0x7fffb745d460 (native @ 0x7fff9f25ac08)],0) ["chrome://browser/content/tabbrowser.xml":492] this = [object ChromeWindow] 4 _callProgressListeners(aBrowser = [object XULElement], aMethod = "onLocationChange", aArguments = [xpconnect wrapped nsIWebProgress @ 0x7fffb69d7860 (native @ 0x7fffb5defd60)],[xpconnect wrapped nsIRequest @ 0x7fffb745d400 (native @ 0x7fffb69cec40)],[xpconnect wrapped nsIURI @ 0x7fffb745d460 (native @ 0x7fff9f25ac08)],0) ["chrome://browser/content/tabbrowser.xml":507] this = [object XULElement] 5 _callProgressListeners([object XULElement], "onLocationChange") ["chrome://browser/content/tabbrowser.xml":595] this = [object Object] 6 onLocationChange(aWebProgress = [xpconnect wrapped nsIWebProgress @ 0x7fffb69d7860 (native @ 0x7fffb5defd60)], aRequest = [xpconnect wrapped nsIRequest @ 0x7fffb745d400 (native @ 0x7fffb69cec40)], aLocation = [xpconnect wrapped nsIURI @ 0x7fffb745d460 (native @ 0x7fff9f25ac08)], aFlags = 0) ["chrome://browser/content/tabbrowser.xml":875] this = [object Object] 7 _callProgressListeners(type = 128, methodName = "onLocationChange", args = [object Object],[obje
Assignee: nobody → ehsan
Comment on attachment 8892508 [details] [diff] [review] Ensure that we always respect the undo/redo transaction history when modifying the <xul:textbox>.value dynamically through script Approval Request Comment [Feature/Bug causing the regression]: Bug 1385525 [User impact if declined]: Comment 0 and the dupes [Is this code covered by automated tests?]: Yes [Has the fix been verified in Nightly?]: No [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: Not really [Why is the change risky/not risky?]: Because the patch is quite simple, it restores the old behavior for XUL text boxes [String changes made/needed]: None
Attachment #8892508 - Flags: approval-mozilla-beta?
Comment on attachment 8892508 [details] [diff] [review] Ensure that we always respect the undo/redo transaction history when modifying the <xul:textbox>.value dynamically through script r=me
Attachment #8892508 - Flags: review?(bzbarsky) → review+
Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/373c6ebaad86 Ensure that we always respect the undo/redo transaction history when modifying the <xul:textbox>.value dynamically through script; r=bzbarsky
https://hg.mozilla.org/mozilla-central/rev/373c6ebaad86
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox56: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Comment on attachment 8892508 [details] [diff] [review] Ensure that we always respect the undo/redo transaction history when modifying the <xul:textbox>.value dynamically through script Made it in before tomorrow's uplift :)
Attachment #8892508 - Flags: approval-mozilla-beta?
Summary: Text in url bar is not rendered correctly → Text in URL/location/address bar is garbled/overlapping/corrupted/not rendered correctly
[bugday-20170801] status-ff56.0a1 : VERIFIED & NOT FIXED. Managed to reproduce the issue on Firefox Nightly under Windows 10 X 64. The issue is still reproducible on Firefox latest Nightly [BuildID : 20170801100311 , 56.0a1 (2017-08-01) (32-bit)]
That's yesterday's nightly, not today's (there's been infra issues delaying the builds). That build isn't expected to have the fix yet.
Flags: needinfo?(madhuri.mittal99)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #30) > That's yesterday's nightly, not today's (there's been infra issues delaying > the builds). That build isn't expected to have the fix yet. You are correct but today is bug verification day and i have this build id ( 20170801100311 )as latest with no new notification (or green icon) available for the new build with the fix :-). In the comments above, it is mentioned FIXED hence i added a comment. :-)
Flags: needinfo?(madhuri.mittal99)
Adding a comment that a build that's not expected to have a fix is still broken doesn't seem very helpful. It only adds confusion to the bug. I'm not arguing against verifying a fixed bug, but you can't do that usefully if you aren't testing the right builds.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #32) > Adding a comment that a build that's not expected to have a fix is still > broken doesn't seem very helpful. It only adds confusion to the bug. I'm not > arguing against verifying a fixed bug, but you can't do that usefully if you > aren't testing the right builds. okay. Thanks for guiding me :-) I will consider this thing ahead.
Blocks: 1386960
(In reply to Madhuri from comment #29) > [bugday-20170801] > > status-ff56.0a1 : VERIFIED & NOT FIXED. > > Managed to reproduce the issue on Firefox Nightly under Windows 10 X 64. > > The issue is still reproducible on Firefox latest Nightly [BuildID : > 20170801100311 , 56.0a1 (2017-08-01) (32-bit)] [bugday-20170802] // due to updates on etherpad link.
[bugday-20170809] status-ff57.0a1 : VERIFIED & FIXED. Managed to reproduce the issue on Firefox Nightly under Windows 10 X 64. The issue is no more reproducible on Firefox latest Nightly [BuildID : 20170808114032 , 57.0a1 (2017-08-08) (32-bit)]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: