Closed
Bug 808114
Opened 13 years ago
Closed 13 years ago
urlbar slow on initial input resulting in lost characters
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
VERIFIED
FIXED
mozilla19
People
(Reporter: mkpdev, Assigned: karlt)
References
Details
(Keywords: regression)
Attachments
(1 file)
2.11 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
When selecting the urlbar and entering a URL, input will freeze for a bit, resulting in one or more characters getting lost. This started on nightlies earlier this week, I believe on Tuesday, 30 October
For example, when just now typing "bugzilla.mozilla.org" in the urlbar, the urlbar contained "bzilla.mozilla.org" before I corrected it
I also tested modifying (but not deleting and re-entering) "www.google.com" (which entered as "www.oglecom") to "www.yahoo.com" ("www.yaho.com")
This usually only happens when substantially changing the location entered in the urlbar, not when making minor changes like corrected "bzilla.mozilla.org" to "bugzilla.mozilla.org"
This does not happen with browser.urlbar.autocomplete.enabled = false or when using the "open web location" dialog
Updated•13 years ago
|
Keywords: regressionwindow-wanted
Comment 1•13 years ago
|
||
I see this as well (I'm also on Linux). I'll search for a regression window this weekend.
Comment 2•13 years ago
|
||
I've got this as a regression window:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e19e170d2f6d&tochange=bed18790882f
Comment 3•13 years ago
|
||
Down to this:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=876a728f389a&tochange=a145ded68994
Looks like fallout from bug 707623
Updated•13 years ago
|
Blocks: 707623
tracking-firefox19:
--- → ?
Component: Location Bar → Widget: Gtk
Keywords: regressionwindow-wanted → regression
Product: Firefox → Core
Assignee: nobody → karlt
Assignee | ||
Updated•13 years ago
|
Assignee: karlt → nobody
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → karlt
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 5•13 years ago
|
||
What's happening here is that CaptureRollupEvents is being called on a
window/widget that has not yet been shown. The gdk_grab_add is effective on
the hidden toplevel GtkWindow widget but that no longer has a focus child
widget to handle the key events because the child MozContainer widget has also
been hidden.
I assume the window is not shown when CaptureRollupEvents is called because
the size is not know at that stage.
#0 IA__gtk_grab_add (widget=0x148cc40) at gtkmain.c:1866
#1 0x00007f572bbc2c4a in nsWindow::CaptureRollupEvents (this=0x628b330,
aListener=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
0x0, aDoCapture=true)
at /home/karl/moz/dev/widget/gtk2/nsWindow.cpp:1852
#2 0x00007f572ac92d5c in nsXULPopupManager::SetCaptureState (this=0x1561ef0,
aOldPopup=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
0x0)
at /home/karl/moz/dev/layout/xul/base/src/nsXULPopupManager.cpp:1567
#3 0x00007f572ac90230 in nsXULPopupManager::ShowPopupCallback (
this=0x1561ef0, aPopup=0x230fc00, aPopupFrame=0x7f5694034268,
aIsContextMenu=false, aSelectFirstItem=false)
at /home/karl/moz/dev/layout/xul/base/src/nsXULPopupManager.cpp:737
#4 0x00007f572ac91836 in nsXULPopupManager::FirePopupShowingEvent (
this=0x1561ef0, aPopup=0x230fc00, aIsContextMenu=false,
aSelectFirstItem=false)
at /home/karl/moz/dev/layout/xul/base/src/nsXULPopupManager.cpp:1206
#5 0x00007f572ac8f9f1 in nsXULPopupManager::ShowPopup (this=0x1561ef0,
aPopup=0x230fc00, aAnchorContent=0x2354df0, aPosition=..., aXPos=0,
aYPos=0, aIsContextMenu=false, aAttributesOverride=false,
aSelectFirstItem=false, aTriggerEvent=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
0x0)
at /home/karl/moz/dev/layout/xul/base/src/nsXULPopupManager.cpp:591
#6 0x00007f572ac64cf2 in nsPopupBoxObject::OpenPopup (this=0x621d000,
aAnchorElement=0x2354e68, aPosition=..., aXPos=0, aYPos=0,
aIsContextMenu=false, aAttributesOverride=false, aTriggerEvent=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
0x0)
at /home/karl/moz/dev/layout/xul/base/src/nsPopupBoxObject.cpp:90
Show is called later at this point:
#4 0x00007f57268afeea in IA__gtk_widget_show (widget=0x148cc40)
at gtkwidget.c:3236
#5 0x00007f572bbc859f in nsWindow::NativeShow (this=0x628b330, aAction=true)
at /home/karl/moz/dev/widget/gtk2/nsWindow.cpp:3910
#6 0x00007f572bbc0f3b in nsWindow::Show (this=0x628b330, aState=true)
at /home/karl/moz/dev/widget/gtk2/nsWindow.cpp:1006
#7 0x00007f572b0fd5b5 in nsView::NotifyEffectiveVisibilityChanged (
this=0x6287250, aEffectivelyVisible=true)
at /home/karl/moz/dev/view/src/nsView.cpp:320
#8 0x00007f572b0fd65c in nsView::SetVisibility (this=0x6287250,
aVisibility=nsViewVisibility_kShow)
at /home/karl/moz/dev/view/src/nsView.cpp:339
#9 0x00007f572b103954 in nsViewManager::SetViewVisibility (this=0x202fee0,
aView=0x6287250, aVisible=nsViewVisibility_kShow)
at /home/karl/moz/dev/view/src/nsViewManager.cpp:1062
#10 0x00007f572ac7680d in nsMenuPopupFrame::LayoutPopup (this=0x7f5694034268,
aState=..., aParentMenu=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
0x0, aSizedToPopup=false)
at /home/karl/moz/dev/layout/xul/base/src/nsMenuPopupFrame.cpp:467
#11 0x00007f572ac83b07 in nsPopupSetFrame::DoLayout (this=0x26ea810,
aState=...)
at /home/karl/moz/dev/layout/xul/base/src/nsPopupSetFrame.cpp:122
#12 0x00007f572ac4e534 in nsIFrame::Layout (this=0x26ea810, aState=...)
at /home/karl/moz/dev/layout/xul/base/src/nsBox.cpp:510
#13 0x00007f572ac54ea5 in nsSprocketLayout::Layout (this=0x254de20,
aBox=0x2045658, aState=...)
at /home/karl/moz/dev/layout/xul/base/src/nsSprocketLayout.cpp:481
#14 0x00007f572ac51863 in nsBoxFrame::DoLayout (this=0x2045658, aState=...)
at /home/karl/moz/dev/layout/xul/base/src/nsBoxFrame.cpp:900
#15 0x00007f572ac4e534 in nsIFrame::Layout (this=0x2045658, aState=...)
at /home/karl/moz/dev/layout/xul/base/src/nsBox.cpp:510
#16 0x00007f572ac589cb in nsStackLayout::Layout (this=0x2665490,
aBox=0x2045350, aState=...)
at /home/karl/moz/dev/layout/xul/base/src/nsStackLayout.cpp:340
#17 0x00007f572ac51863 in nsBoxFrame::DoLayout (this=0x2045350, aState=...)
at /home/karl/moz/dev/layout/xul/base/src/nsBoxFrame.cpp:900
#18 0x00007f572ac4e534 in nsIFrame::Layout (this=0x2045350, aState=...)
at /home/karl/moz/dev/layout/xul/base/src/nsBox.cpp:510
#19 0x00007f572ac50fab in nsBoxFrame::Reflow (this=0x2045350, aPresContext=
0x21e9370, aDesiredSize=..., aReflowState=..., aStatus=@0x7fffab4bebcc: 0)
at /home/karl/moz/dev/layout/xul/base/src/nsBoxFrame.cpp:695
#20 0x00007f572ac4d076 in nsRootBoxFrame::Reflow (this=0x2045350,
aPresContext=0x21e9370, aDesiredSize=..., aReflowState=...,
aStatus=@0x7fffab4bebcc: 0)
at /home/karl/moz/dev/layout/xul/base/src/nsRootBoxFrame.cpp:199
#21 0x00007f572aa5b639 in nsContainerFrame::ReflowChild (this=0x2044a90,
aKidFrame=0x2045350, aPresContext=0x21e9370, aDesiredSize=...,
aReflowState=..., aX=0, aY=0, aFlags=0, aStatus=@0x7fffab4bebcc: 0,
aTracker=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
0x0)
at /home/karl/moz/dev/layout/generic/nsContainerFrame.cpp:953
#22 0x00007f572ab104aa in ViewportFrame::Reflow (this=0x2044a90,
aPresContext=0x21e9370, aDesiredSize=..., aReflowState=...,
aStatus=@0x7fffab4bebcc: 0)
at /home/karl/moz/dev/layout/generic/nsViewportFrame.cpp:203
#23 0x00007f572a9f0454 in PresShell::DoReflow (this=0x20397e0,
target=0x2044a90, aInterruptible=false)
at /home/karl/moz/dev/layout/base/nsPresShell.cpp:7529
#24 0x00007f572a9f0bc8 in PresShell::ProcessReflowCommands (this=0x20397e0,
aInterruptible=false)
at /home/karl/moz/dev/layout/base/nsPresShell.cpp:7670
#25 0x00007f572a9e4028 in PresShell::FlushPendingNotifications (
this=0x20397e0, aType=Flush_Layout)
at /home/karl/moz/dev/layout/base/nsPresShell.cpp:3913
#26 0x00007f572ad487f2 in nsDocument::FlushPendingNotifications (
this=0x2017de0, aType=Flush_Layout)
at /home/karl/moz/dev/content/base/src/nsDocument.cpp:6112
#27 0x00007f572ad8a10f in nsGenericElement::GetPrimaryFrame (this=0x62bb1a0,
aType=Flush_Layout)
at /home/karl/moz/dev/content/base/src/nsGenericElement.cpp:1625
#28 0x00007f572ad87140 in nsGenericElement::GetBoundingClientRect (
this=0x62bb1a0)
at /home/karl/moz/dev/content/base/src/nsGenericElement.cpp:656
#29 0x00007f572b786662 in nsIDOMElement_GetBoundingClientRect (cx=0x1f73850,
argc=0, vp=0x7f5715a44368)
at /mnt/sda10/karl/obj/js/xpconnect/src/dom_quickstubs.cpp:2347
(In reply to Alex Keybl [:akeybl] from comment #4)
> Is there any reason to not just back out bug 707623 for the time being?
Only that it will reintroduce the bug that fixed. That is definitely the
preferred bug to have, but this is easy to fix (now that I know the cause).
Assignee | ||
Comment 6•13 years ago
|
||
gtk_widget_grab_focus is a simpler version of gtk_window_set_focus, doing
exactly the same thing when the argument is non-null.
http://developer.gnome.org/gtk/2.24/GtkWindow.html#gtk-window-set-focus
This also saves a little of the child widget layout work that GTK does when
child widgets change.
Attachment #681788 -
Flags: review?(roc)
Attachment #681788 -
Flags: review?(roc) → review+
Assignee | ||
Comment 7•13 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=3f4498e1c55e
https://hg.mozilla.org/integration/mozilla-inbound/rev/a9500b386854
Perhaps it may be possible to write a chrome mochitest if SynthesizeNativeKeyEvent were implemented using gdk_event_put().
Flags: in-testsuite?
Comment 8•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
status-firefox19:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Comment 10•12 years ago
|
||
User Agent: Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130206083616
Works for me on Firefox 19 beta 5 and on Nightly from 2012-10-30 (Build id: 20121030030633) too. Do I need some specific Linux distribution OS (I'm using Ubuntu) to verify this issue?
Assignee | ||
Comment 11•12 years ago
|
||
No specific distribution should be required. Try a nightly from 2012-11-02.
Comment 12•12 years ago
|
||
It works for me also on nightly from 2012-11-02 (Build ID: 20121102030726). Can someone who has encountered this issue verify the fix?
You need to log in
before you can comment on or make changes to this bug.
Description
•