mozilla :: #fx-team

13 Sep 2017
07:44nhnt11is it possible to have a browser window without a urlbar? some sort of popup window? (I think not, but I'm not sure)
07:53nhnt11dao: ping
07:53nhnt11er, meant to ping you on #photon-visual
08:02johannhnhnt11: as I recently found out, yes
08:02johannhnhnt11: one second, I'll look up the bug
08:02nhnt11johannh: I swear I vaguely remembered you talking about this and that sparked my doubt :D
08:03johannhyeah it's a bit annoying, we've had this whole discussion about not allowing to hide the tabstrip/urlbar and then there are popups that do it anyway
08:05firebotBug 1385194 FIXED, HTML5 notification permission request is not shown when HTML page is opened from Firefox add-on
08:06johannhI love the effect the tab burst has when restoring my pinned tabs
08:18nhnt11is there a way to set the width of two elements, without causing reflow between setting them?
08:18nhnt11i.e., I want to set width on A, and B, and reflow after both have been set
08:20* nhnt11 is looking around
08:20johannhnhnt11: but you're not querying style between setting those widths, right?
08:20nhnt11johannh: I'm not
08:20nhnt11it should be fine, rihgt?
08:21johannhthen that should be fine off-hand, yeah
08:21nhnt11hmm, that's what I thought
08:21nhnt11I'll elaborate further about my actual problem in a sec
08:22johannhyou're not causing a flush and it will just get drawn in the same tick or whatever you call it
08:23nhnt11it's not my fault :D
08:23johannhyou should try oh no reflow, it's quite accurate I've found
08:23nhnt11johannh: so, let me talk about what I'm doing
08:23nhnt11on a new profile, the URL and search bars don't have width attributes set
08:23johannhah, that bug :D
08:24nhnt11they're set when you drag the splitter between them a bit
08:24nhnt11you can move the splitter just 1px, and the attributes will be set to the current clientWidths
08:24nhnt11now that these attributes are set
08:24nhnt11If you open a new window
08:24nhnt11The attributes persist
08:24nhnt11but the clientWidths *no longer match the attributes*
08:25nhnt11i.e. if you're on a new profile, and adjust the splitter by 1px, next time you open a new window, the url and search bars will be bigger than they were in the original window
08:26johannhok, so that's because the attribute is persisted somehow, which makes sense, right?
08:27johannhand what do you mean by clientWidths no longer match the attribute?
08:27nhnt11johannh: it doesn't make sense because the widths end up being different from the attribute value
08:27johannhso the clientWidth is giving you the correct width?
08:29nhnt11johannh: so on a new profile, with a maximized firefox window on my macbook, the url bar is 642px and the search bar is 315px
08:29nhnt11if I adjust the splitter a bit, the width attributes are set to those values
08:29nhnt11then I open a new window
08:29nhnt11the attributes are still the saem
08:29nhnt11but the actual computed widths are now 737px and 339px
08:30johannhthe same means 642px or whatever you adjusted it to?
08:30Gijsmikedeboer: good morning! :D
08:31Gijsmikedeboer: can I help with some of the downloads followup bugs, and if so which one would be a good one to start with?
08:31nhnt11johannh: well, I adjusted it to 641px, but yeah, whatever I adjusted it to
08:31nhnt11by "a bit" I meant, negligably
08:31johannhnhnt11: ah
08:31nhnt11negligibly *
08:32nhnt11johannh: you can try it easily, just clear the width attributes from the browser toolbox
08:32johannhnhnt11: technically a fresh profile shouldn't have a search bar anyway though
08:32nhnt11johannh: yeah, which makes life easier for me ;)
08:33johannhhm is it related to the flexible spaces?
08:33nhnt11johannh: that's what I was wondering
08:33nhnt11it's odd
08:33johannhwhen I try this it seems like both reduce the flexible space somehow
08:33johannhGijs maybe has an idea
08:35* Gijs reads some more...
08:36mikedeboerGijs: well, always!
08:36Gijsjohannh: no idea, but I noticed similar behaviour a while back... someone pointed out to me that their flexible spacers were a lot smaller than they were in a clean profile
08:36Gijsand it was because of this bug
08:37Gijsjohannh: nhnt11: tbh, I'm inclined to chalk it up to "XUL is effing weird" and move on
08:37Gijsnhnt11: is this causing an actual bug somewhere/somehow?
08:37nhnt11Gijs: That was my plan too :D
08:37johannhheh, seconded
08:37nhnt11Gijs: there is an "actual bug" but I would estimate that about 0 users would ever encounter it
08:37nhnt11and once I land this patch the "actual bug" will completely go away in userland
08:38Gijsnhnt11: I mean, is there anything else besides the clientwidth and width not matching?
08:38nhnt11I just wanted to be sure that my patch wasn't changing a behaviro
08:38Gijsyeah, no, it's not
08:38mikedeboerGijs: so bug 1398289 would be the most important one methinks
08:38firebot NEW, Library > Downloads Panel sub-label font-size is too small
08:38Gijsmikedeboer: OK. Do you know off-hand if there's something wrong with the suggestion from Aaron to use .9em ?
08:38* Gijs assumes there was a reason to use .7em
08:39mikedeboerGijs: it's basically changing it to .9em ;)
08:39Gijsmaybe osx vs. windows?
08:39nhnt11ugh, can we do something to protect the default profile
08:39mikedeboerno, it's fine on OSX as well
08:39Gijsnhnt11: "protect" ?
08:39nhnt11Every time I run my local build with -P I'm hit by waves of anxiety
08:39nhnt11because I'm scared of accidentally deleting my default profile
08:39mikedeboerGijs: the .7em was arbitrary because it looked nice on OSX
08:39nhnt11I know there's a confirmation modal, but still...
08:39johannhnhnt11: make a backup? :)
08:40Gijswhat johannh said :)
08:40johannhnhnt11: my default profile is named differently, I don't think there's a viable way to do it ;)
08:40Gijsalso sync can save most of your stuff
08:40johannhyeah, also that
08:40nhnt11Gijs: yep, I use sync
08:40nhnt11so I'm not too worried
08:40nhnt11but still...
08:40Gijsmikedeboer: ok, this seems like about the right complexity for <10am for me... :P
08:40nhnt11I just don&#39;t want my default profile to be in the picture at all when I&#39;m messing around on a local build
08:41nhnt11for example, I don&#39;t want to start a local build with my default profile by mistake
08:41mikedeboerhaha good!
08:42Gijsffs, this win10 insider dpi bug is going to drive me mad pretty quickly
08:42Gijsmy vidyo titlebar is OK but the contents of the window are half-size
08:43Gijsfor gvim and conemu it&#39;s the other way around (titlebar tiny, contents of the window are blurry)
08:43GijsFirefox is mostly OK except our calculations for the titlebar are slightly off and so fitts law breaks for using tabs in maximized windows :|
08:44nhnt11ugh, WTF is this:
08:44nhnt11I didn&#39;t even change anything
08:47nhnt11well, already clobbered, so never mind...
08:47* nhnt11 wonders if anyone here would find his `hg pullr` alias useful
08:48nhnt11(It pulls and then rebases all bookmarks onto the new central)
08:48* Gijs doesn&#39;t use bookmarks
08:49Gijsalso, IME it&#39;s annoying to review rebased patches in mozreview because the interdiff gets messed up
08:49nhnt11Gijs: I have aliases that take the bug number from the commit message and set the bookmark name to <bug>.patch
08:49Gijsso I try to avoid rebasing patches until/unless I have to
08:49nhnt11it&#39;s useful for automation
08:49nhnt11hmm, good point
09:36* johannh too
12:05nhnt11hmm, the &quot;Private Browsing with Tracking Protection&quot; heading in about:privatebrowsing seems to be smaller than the main text in the page?
12:05nhnt11is this a regression
12:05* nhnt11 thinks it is
12:06nhnt11lol, it seems like the `html|html *` selector in common.css beats the .title selector in info-pages.css
12:08nhnt11ok, it&#39;s definitely a regression
12:10* nhnt11 is annoyed at this
12:11* johannh invites nhnt11 to resolve bug 1398730
12:11firebot NEW, Should have a configuration for private windows
12:11nhnt11regressed by bug 1392532, it seems
12:11firebot FIXED, The font size on Linux is too huge, compared to Mac and Windows.
12:11johannhthat bug did a lot of stuff
12:23nhnt11oh noooooo
12:24nhnt11Gijs_away: so, my patch for bug 1370401 does away completely with setting a min-width on #urlbar-container
12:24firebot ASSIGNED, URL bar icons overflow the URL bar when the width of the window is reduced to the minimum
12:24nhnt11I notice your patch for the download button autohide stuff introduces some calc&#39;s
12:25* nhnt11 will ping you again when you&#39;re not _away
12:25Gijsnhnt11: uhm. This sounds problematic
12:26Gijsnhnt11: the aim of the calc() stuff is that nothing ends up in the overflow panel when the downloads button appears.
12:26nhnt11Gijs: you mean, the downloads button doesn&#39;t end up in the overflow panel?
12:26Gijsnhnt11: no, that can&#39;t happen. I mean, other buttons don&#39;t end up in the overflow panel
12:27nhnt11ah, I see
12:27Gijs(the downloads button has overflows=false)
12:27nhnt11so that they don&#39;t get pushed in and out?
12:27GijsI don&#39;t know how you would achieve the same result if you&#39;re removing min-width altogether
12:28nhnt11Gijs: setting min-width is crappy, because there&#39;s way too much stuff going on in the urlbar now
12:28nhnt11it&#39;s impossible to tell what a good min-width is
12:28nhnt11because of page action buttons, identity label, container label...
12:28Gijswell, I hope you&#39;re still setting a min-width on the actual inputbox inside the urlbar container
12:28nhnt11My patch added a min-width to the input box, which didn&#39;t exist before
12:29Gijsso we can achieve the same result by manipulating that min-width.
12:29nhnt11(it was very possible for the inputbox to be 0px wide)
12:29Gijsdepends a bit on XUL :)
12:29nhnt11Gijs: nah, the min-width is quite small, I think
12:29nhnt11hmm, but it might be enough?
12:29Gijshow small is quite small?
12:29Gijsthat wouldn&#39;t be enough to show a meaningful domain name...
12:30nhnt11Gijs: I just wanted it to be enough to be clickable, lol
12:30nhnt11(for now)
12:30Gijsdoes your patch still manipulate the size of the identity box based on window size?
12:30nhnt11Gijs: no
12:30Gijsthat doesn&#39;t seem right, then...
12:30nhnt11the identity box already flexes
12:30Gijsthe &quot;whole point&quot; of that stuff is to avoid the url bar becoming spoofable
12:31Gijsyes, but if you go to some swiss bank site it ends up taking half the window
12:31Gijswe don&#39;t want that.
12:31Gijsthe code I&#39;m changing also contains a varying max-width for the identity box
12:31nhnt11Gijs: ok, let me mess around/think about things and get back to you on all this
12:31* nhnt11 has to get into a meeting
12:31Gijsthat will probably need to be kept
13:13Gijsmikedeboer: so a bunch of the other bugs are related to &quot;file moved or missing&quot;... do you know what&#39;s needed there?
13:14mikedeboerGijs: yes, bug 1395615
13:14firebot NEW, Implement the &quot;file moved or missing&quot; check in download item onChange handlers
13:21Gijsmikedeboer: OK, but do you know roughly what it takes to implement this? Are you planning on working on this, should I, or is this post-57 work, or...? :)
13:33nhnt11Gijs: So, I&#39;m guessing it was a very deliberate decision to put the downloads button immediately adjacent to the url bar?
13:33Gijsnhnt11: well, plus/minus any spacers and/or the search bar
13:34Gijsbut yes
13:34Gijss/\/minus//, I suppose
13:34Gijsbut there we are
13:34nhnt11Gijs: Hm, so if I remove all of the new min-width rules you added, I can&#39;t reproduce the stuff-goes-into-overflow issue
13:35nhnt11I expect this is a direct result of my patch
13:35nhnt11however, there is another issue: if the window is small the downloads button is just invisible
13:36nhnt11I&#39;ll explain
13:36GijsI don&#39;t understand how you can both not have anything in the overflow *and* have stuff disappear
13:36Gijsunless you broke how the overflow button works
13:36Gijsand that doesn&#39;t seem good...
13:36nhnt11hold on
13:36nhnt11if you make the window small enough, all the toolbar buttons overflow
13:37nhnt11after that, if you continue making the window smaller, the hbox that contains the urlbar and the toolbar buttons simply gets too small
13:37nhnt11and the urlbar overflows it, but overflow is hidden
13:37nhnt11at this point, if you add the downloads button, it&#39;s invisible
13:37nhnt11because it&#39;s added after the urlbar which is already overflowing
13:38nhnt11what we need is rules to collapse the page action buttons for small windows
13:38nhnt11give me a few minutes
13:41mikedeboerGijs: I&#39;m planning to work on it, but only when Paolo gets back, because he has it all thought out
13:41mikedeboerGijs: so it might also be that he&#39;ll simply take it
13:42nhnt1119:11:28 - nhnt11: yay, more bugs
13:42nhnt1119:11:52 - nhnt11: seems like pinning the downloads button to the overflow menu once it appears causes everything else already in the overflow menu to disappear :)
13:49nhnt11my downloads button is broken
13:51nhnt11Gijs: help :(
13:51nhnt11the downloads button no longer appears when I start a download
13:51nhnt11it&#39;s not in the overflow panel
13:51nhnt11it&#39;s not available in the customize ui
13:51Gijsnhnt11: errors in the browser console?
13:51nhnt11nothing relevant
13:52nhnt11as far as I can tell
13:57Gijsnhnt11: str from a clean profile would be helpful at this stage
13:57Gijsnhnt11: also whether this reproduced before my changes
13:57nhnt11working on it
13:58nhnt11I think it&#39;s because I tried to pin it to the overflow panel
13:58Gijsnhnt11: we&#39;ve had issues with toolbar buttons with stacks vs. panels before now.
13:58Gijsthat&#39;s allowed :)
13:58Gijsit&#39;ll implicitly turn off autohide
13:58Gijswell, should, anyway
14:04nhnt11Gijs: got some STR for you
14:04nhnt111. start a download
14:04nhnt112. right click download button, remove from toolbar
14:04nhnt113. restart firefox
14:05nhnt11after this, downloads button does not automatically appear when you start a download, and is not available in customize mode
14:05nhnt11unless I&#39;m missing something
14:06nhnt11this is on a build using m-c pulled after your patch landed
14:06nhnt11(pulled less than 2 hours ago I think)
14:06Gijsnhnt11: the first would be expected... you removed it, so why would it appear?
14:06Gijsthe second less so
14:06Gijsit should be in the palette / grid
14:06Gijsthat grid is pretty cluttered
14:07nhnt11Gijs: This is the entire grid I see:
14:07nhnt11overflow panel is empty
14:07Gijsnhnt11: ok, please file a followup bug, I&#39;ll take a look.
14:08nhnt11the button appears in the grid between Search and Flexible Space, before Firefox is restarted
14:08nhnt11cool, will do
14:13Gijsthanks :)
14:14nhnt11Gijs: Bug 1399490
14:14firebot NEW, Downloads button is inaccessible after removing it from the toolbar and restarting Firefox
14:14nhnt11(I didn&#39;t set any flags, sorry)
14:15Gijsmikedeboer: hrm, but paolo won&#39;t be back until after merge day, right?
14:15Gijsmikedeboer: do you think it&#39;s OK not to do anything about that set of bugs until then, and uplift everything? Feels like we might need strings...
14:15* nhnt11 needs a beer, long day
14:24* Gijs tries to stay calm in the face of people complaining on the bug that things aren&#39;t there for them
14:24makGijs: I&#39;m with you, stay calm :)
14:25makthis bug has far too much magic and backouts in the past. That&#39;s why I originally said reintroducing magic buttons in the toolbar was a bad idea :\
14:25maktechnical debt to be paid immediately
14:29mikedeboerGijs: true, so we&#39;ll need to uplift that. However, we won&#39;t need new strings, since the functionality is there and working in the session downloads button
14:29mikedeboer(the one you and nhnt11 are having sooo much fun with ;) )
14:35Gijshm, this is fun :|
14:51bwintonHow are the things in the grid ordered? (I frequently find it hard to locate the button I&#39;m looking for)
15:03Gijsbwinton: order of definition, I think, no real ordering to speak of
15:03Gijsthere are at least 3 bugs on file to improve this
15:06bwintonHeh. Sounds about right. :)
15:26Gijsnhnt11: patch up, r?you :)
15:38mikedeboermeh, might as well work on the &#39;moved or missing&#39; thing now
15:48Gijsmikedeboer: can you make the meeting today?
15:48mikedeboerGijs: yes
15:48Gijsawesome, thanks
15:49* Gijs tries to figure out the stupid arrow positioning in customize mode
15:50Gijsahhh, maybe I&#39;ve found it
16:02jawsdao: hey, do you think you&#39;ll get to the reviews for bug 1383051 today? i can steal them but i&#39;d like your opinion on them
16:02firebot ASSIGNED, Add a visual indicator when accessibility is enabled
16:14jawshow do i get rid of the blue dot on the Nightly logo on about:newtab?
16:14jawsi&#39;ve clicked on each step of the tour as well as clicking &quot;skip tour&quot;
16:16Mossopjaws: You can&#39;t, it&#39;s a known bug
16:16jawsMossop: okay was gonna file it
16:16jawsgood to know it&#39;s already on file
17:25jawsdid anything with the padding of bookmark toolbar items change recently?
17:27jawsnevermind, i see now
17:27firebotBug 1388700 FIXED, Increase horizontal margin/padding of bookmarks toolbar items
17:27johannhjaws: yup :)
17:28jawsjohannh: but i&#39;m not seeing the increased padding in mozregression builds...
17:28jawsnor my local build
17:29johannhcan you hover between the bookmark items without triggering hover on one? then you have it
17:29jawsor, my Nightly build is showing Touch density for the bookmarks toolbar, but in Customize mode it is set to Normal
17:29johannhoh you mean only the padding?
17:42johannhjaws: not sure I understand it fully, do you mean there&#39;s a bug?
17:42jawsjohannh: i think so, i&#39;m still trying to figure out where/how this happened
17:42johannhjaws: ok, feel free to file a bug :)
17:42johannhmaybe I understand it better when I read it in bug-form :D
17:44jawsjohannh: do you know if a bug is on file for the &quot;Title bar&quot; checkbox label in Customize Mode being unreadable when Dark theme is enabled?
17:44johannhjaws: yes, one sec
17:44jawsok no need
17:44jawsjust wanted to make sure it was filed
17:45johannhjaws: bug 1398549
17:45firebot NEW, &#39;Title Bar&#39; checkbox label in customization mode with Dark theme is impossible to read
17:45johannhyes :)
17:45jaws:) thx anyways
17:45johannhso many small bugs
17:46* johannh love-hates finishing projects
17:47jawsjohannh: i figured it out. if the PlacesChevron is visible the height of the bookmarks toolbar increases by 10px
17:48johannhjaws: aaah, there&#39;s also a bug for that already
17:48* johannh should have known it was this
17:48johannhso many small bugs
17:48* jaws enjoys finding out that these aren&#39;t *new* bugs
17:49johannhyes, and I have a WIP patch for that one but have been prioritizing other stuff because it&#39;s really hacky
18:08felipegandalf: ping
18:09gandalffelipe: pong
18:09felipegandalf: hey, I think it&#39;d be nice to uplift bug 1386015 if there&#39;s still time. What do you think?
18:09firebot FIXED, [e10s] <option> elements with inherited colors generates very inefficient styling in the parent
18:11gandalffelipe: I&#39;d be happy to see that, but I don&#39;t have cycles to adapt the patch if it doesn&#39;t apply cleanly :(
18:12felipegandalf: I don&#39;t think it will have merge conflicts, but I&#39;ll sign up for handling it if necessary
18:12gandalffelipe: cool! thanks! Do you want me to request uplift?
18:12felipegandalf: could you fill the uplift request?
18:12gandalf :D
18:53gandalfJohn-Galt: one more q. I got the removeAttribute to happen only if the anonid==initialBrowser. That fixes most of the tests affected, except of two which test restoring. It seems that when we restore, the tests expect nodefaultsrc to be there even for the initialBrowser. Do you know how can I differentiate between extension and restoring of tabs from within
18:53gandalfof updateBrowserRemoteness?
18:54mconleyPour one out for the Add-on SDK:
18:54firebotBug 1371065 FIXED, Remove the addon SDK from Firefox
18:57RyanVMmak: can you create the pref flip patch? :)
18:57John-Galtgandalf: Hm. But we never would have had nodefaultsrc on that browser before...
19:00makRyanVM: I suppose so, give me a few mins (sorry, I currently have a problem to my left shoulder that makes me a slow typer)
19:00RyanVMok, thanks - just not sure if the TPE folks will be around to do it otherwise since the b12 gtb is going to happen later today still
19:03gandalfJohn-Galt: it seems that if I remove the nodefaultsrc from initialBrowser in updateRemoteness, it&#39;s this one that fails :
19:03gandalfI&#39;m still confirming
19:11johannhdo we have a bug for the tab overflow buttons jumping down when you drag a tab?
19:11johannhmaybe jaws knows that one?
19:11jawsjohannh: yes, one moment
19:12jawsjohannh: i have an r+ patch to fix that,
19:12johannhhah, together we know all the bugs!
19:12firebotBug 1398230 ASSIGNED, &quot;Open a new tab&quot; and &quot;List all tabs&quot; move when dragging tab
19:13jawsyessir! :P
19:13makRyanVM: patch posted, could you please take care of landing it in beta?
19:14RyanVMwill do, thanks
19:26aswanany l10n experts in the house? is it okay to move a string from a .dtd file to a .properties file if i keep the identifier and the english string the same?
19:27johannhinteresting question
19:34gandalfaswan: yeah
19:34aswangandalf: excellent, thanks
20:27gandalfeeejay: ping
20:29eeejaygandalf: pong
20:31gandalfeeejay: would you have a bit of time to help me with today?
20:31firebotBug 1397365 ASSIGNED, Set nodefaultsrc on initialBrowser in tabbrowser.xml
20:31gandalfthe change I&#39;m making to initialBrowser to not create the about:blank intrinsically seems to make the first page not scroll and I&#39;d like to verify if it&#39;s a bug in test, code, or expected behavior change
20:33eeejaygandalf: &quot;intrinsically seems&quot;, is it the desired behavior?
20:36eeejaygandalf: didn&#39;t try your patch, but you are describing the problem in your comment
20:36eeejaygandalf: screen readers expect a scroll event after the page load. otherwise they don&#39;t know where in the page they should start reading
20:37rhelmerhm. why does gBrowser.addEventListener(&quot;DOMContentLoaded&quot;, ...) fire for about:newtab but not about:home (on 55 fwiw)
20:37rhelmeris there a single event I can listen for that&#39;ll fire on both?
20:38Mossoprhelmer: Because about:home is loaded in the content process but about:newtab isn&#39;t there. You need to listen from a framescript to catch both
20:38rhelmerMossop: ah that makes sense, thanks.
20:39gandalfeeejay: so in the new behavior the scroll.html#link1 is the very first URL loaded. Nothing gets loaded before. And I believe that it causes the scrolling never to happen because it just opens the browser already scrolled
20:39gandalfeeejay: does it make sense?
20:40eeejaygandalf: it does. and i understand why that is an accessibility regression, do you?
20:40gandalfpossibly. It depends. :)
20:40gandalfso, if you open a new tab to scroll.html#link1 it will also not scroll
20:40gandalfit&#39;ll just open the browser at the scrolled position
20:41gandalfmy patch unifies the initialBrowser (so, the first tab) behavior with that of other tabs
20:41eeejaygandalf: i&#39;m curios what the DOM event behavior is. if you listen for &#39;scroll&#39; after &#39;load&#39;, do you get anything before the patch? and what about after?
20:41gandalfI&#39;ll test that
21:25gandalfeeejay: I added
21:26gandalfeeejay: both with and without my patch I see one `scroll` and one `onload fired` in that order
21:26eeejayhm interesting..
21:27eeejaygandalf: if i apply the &quot;complete patchset&quot; attachment, will i be able to look at this locally?
21:29gandalfeeejay: yes!
21:29gandalfeeejay: actually. I noticed something. When the test opens, it scrolls and freezes
21:29gandalfbut if I click anywhere in the document (so, give it focus), it passes
21:29eeejaygandalf: what os are you on?
21:30eeejayyeah, we have a lot of focus dependent tests which really sucks
21:30eeejaygandalf: did you try this test in try?
21:30gandalfmaybe my patch removes some intermittents
21:30gandalfeeejay: not recently. I can push it to try to see
21:30gandalfI can also check on mac
21:31eeejayasking because the focus quirks make these tests shaky, and sometimes work better in try
21:32gandalftested on mac, same thing
21:32gandalfI&#39;ll push to try
21:34gandalfeeejay: weird, so doing `document.body.focus()` doesn&#39;t help from within of scroll.html
21:34gandalfbut those two lines show up only after I focus:
21:34gandalf4 INFO TEST-PASS | accessible/tests/mochitest/events/test_scroll.xul | Test with ID = &#39;load tab: http://mochi.test:8888/a11y/accessible/tests/mochitest/events/scroll.html#link1&#39; succeed. Event &#39;document load complete&#39; was handled.
21:34gandalf5 INFO TEST-PASS | accessible/tests/mochitest/events/test_scroll.xul | Test with ID = &#39;load tab: http://mochi.test:8888/a11y/accessible/tests/mochitest/events/scroll.html#link1&#39; succeed. Event &#39;scrolling start&#39; was handled.
21:40eeejaygandalf: yeah, looks like SCROLLING_START is sent after the doc is focused
21:41gandalfI can probably dirty hack around it by forcing some other url to load into that first tab first, then load the scroll.html, but it seems very nasty
21:41eeejaygandalf: i guess the question is, why is the doc not focused?
21:43gandalfthat I don&#39;t know...
21:44gandalfmaybe we focus only after loading a document?
21:44gandalfbut then, loading scroll.html should focus...
21:45eeejaygandalf: yeah.. doing some more debugging here
21:46gandalfthank you! I&#39;m looking through the code as well, but it&#39;s pretty unfamiliar
21:48gandalfeeejay: for what its worth, the browser window is focused according to my GTK
21:50RyanVMmconley: I&#39;m wishing right about now that the big in-content pref pane removal waited a cycle
21:51RyanVMtrying to rebase a patch that landed on 57 after that to 56
21:51RyanVMbug 1397723
21:51firebot FIXED, Some strings show up as a tooltip even though the string was not found
21:51mconleyRyanVM: need assistance?
21:52RyanVMif you could, I would very-much appreciate it
21:52RyanVMit&#39;s not as trivial as s/in-content/in-content-new like I was hopeing
21:52RyanVMhoping* even
21:52* mconley pulls beta
21:53* RyanVM hopes bug 1397729 goes better
21:53firebot FIXED, Strings inside cookies dialog are not found when searched
21:54gandalfeeejay: one thing I noticed is that in another test it seems that the focus goes directly to address bar. Maybe it&#39;s the same here?
21:55RyanVMmconley: bug 1397729 is going to need some help too :\
21:56RyanVMand I&#39;ll just go ahead and assume bug 1397731 will as well
21:56firebot FIXED, Highlight is not removed from dialogs after searching for something and picking a category from Pref
21:57RyanVMMattN: bug 1386922 needs rebasing for Beta too
21:57firebot FIXED, [Form Autofill] Add &quot;Learn more&quot; links to SUMO pages in preferences
21:59gandalfmconley: any idea why nodefaultsrc would make us focus url bar instead of the tab?
21:59mconleyRyanVM: seems like some of the tests that bug 1397723 touches don&#39;t exist on beta.
21:59eeejaygandalf: looks like the focus is in the awesomebar during the test
22:00eeejaywhen it should be in the doc
22:00eeejayoh dopes, you just saw that too
22:00gandalfso maybe, since we remove the initial about:blank from the initialBrowser, we focus addressbar.
22:00gandalfmconley: should we add a focus to doc when the first document is loaded?
22:01gandalfor should we fix tests to focus on the doc?
22:01mconleyRyanVM: hrm - this is more re-basing than I think I have time for - I gotta head out. :( So, I&#39;ve done one. Maybe ni? Ricky to do the others (and maybe verify the one I just sent you?)
22:01eeejaygandalf: looks like you figured out the issue..
22:01gandalfeeejay: I saw it in a different test! It would be nice if there was one fix for both :)
22:01gandalfeeejay: yeah, thank you!
22:02gandalfeeejay: and John-Galt pointed out that maybe we should fix that ;)
22:03RyanVMmconley: ok - it&#39;ll miss b12 then though
22:03RyanVMwe&#39;re building it tonight and nothing else until the RC next week
22:03mconleyRyanVM: oh geez. :( Sorry - maybe jaws can help? I&#39;m starting to pack up over here
22:04gandalfmconley: before you head out. Any chance you can chime in on the focus thing?
22:04* mconley scans backscroll
22:05mconleygandalf: Unsure. Presumably we have some code that focuses content after a page load.
22:05mconleythe initial load
22:05RyanVMmconley: thanks for doing the rebase - that one applies :)
22:05mconleygandalf: is this in a new window?
22:06gandalfmconley: my guess is that when we open a window we try to focus on the document. But with nodefaultsrc there&#39;s no document to focus, so we focus urlbar
22:07mconleygandalf: maybe this stuff isn&#39;t getting triggered?:
22:07mconley might be returning early
22:07mconleythat&#39;s the area of code I&#39;d examine. Compare that with behaviour when nodefaultsrc isn&#39;t there, I guess
22:08gandalfeeejay: thank you, I hope the fix to focus will make two tests pass without changes :)
22:10jawsRyanVM: i&#39;ll see what i can do
22:10eeejaygandalf: great. yeah, this seems to be a functional regression (focus should land on document of new tab, not address bar)
22:10RyanVMjaws: just bug 1397729 at this point
22:10firebot FIXED, Strings inside cookies dialog are not found when searched
22:11RyanVMI was able to rebase one of them and mconley did one
22:24jawsRyanVM: needinfo for you on bug 1397729
22:24firebot FIXED, Strings inside cookies dialog are not found when searched
22:24RyanVMwill land it shortly
23:13RyanVMgandalf: ping
23:13MattNRyanVM: working on the one rebase
23:13RyanVMMattN: awesome, thanks
23:14RyanVMi still have one or two more patches to land tonight, so go ahead and attach it to the bug when ready
23:43gandalfwhat&#39;s the function in browser/base/content/browser.js that is called when document finishes loading?
23:44RyanVM|dinnerjaws: is looking pretty permafail
23:44jawssorry i have to head out right now
23:44RyanVM|dinnerscreenshot is telling
23:53gandalfdao: ping
23:59jawsyeah i see that now. that&#39;s weird. i built and tested it. i should have tried flipping the pref...
23:59jawsdoing a clobber build now
14 Sep 2017
No messages
Last message: 6 days and 15 hours ago