1546019 - Caret would not appear on input field if open web page in Current Tab

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Alice0775 White]

Reproducible: always:

Steps to reproduce:

1. Open https://www.google.com/ in new tab
2. (optionally) Click on Input field in the page

Actual Results:
Caret would appear. But I can type text.
After switch to another application or tab, then the caret appears.

Expected Resilts:
Caret should appear

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b97df75c9365a162675d962354083af7b5fb40b9&tochange=98adabf295d0bdd1d48cf715fb8ac8ea4ead8766

Regressed by:
98adabf295d0 Kyle Machulis — Bug 1542415 - Pref on frameloader rebuilding by default; r!nika r=nika

:kmachulis,
Your patch seems to cause thw regression. Can you please look into this?

Comment 1

[Alice0775 White]

Sorry correction,

Steps to reproduce:

1. Open https://www.google.com/ in current tab
2. (optionally) Click on Input field in the page

And this happens not only Google but also any web page if open in Current Tab.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

I am not sure Document Nagivation is the right component or not.

Comment 4

[[e-mail]]

I've also experienced this issue, it also happens on various sites where there are input fields for login in.

In case this helps narrow, I found that switching to another existing tab and coming back to the tab with the issue fixes the issue (no need to reload anything).

Comment 6

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

:mats, I was pointed at you to talk to about this because it's apparently something to do with layout.

The current STR after backout:

1. In about:config, set fission.rebuild_frameloaders_on_remoteness_change to true
2. Follow steps in Comment 0

Not real sure where to start on this since I'm not really familiar with layout, but due to the fact that, with this pref, we're rebuilding frameloaders without actually doing xulbrowser bring up, I figure there's probably some step in the process that we're missing.

Comment 7

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Bug 1546022 may also be related to this issue.

ni?'ing emilio in since they offered to help earlier today too. :)

Comment 8

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Annnd also bug 1546103, though I had problems repro'ing that. I've been centralizing on this bug because it was the first 100% repro I could use.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I took a look and this and I think I have a fix.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1546019 - When a focused browser changes remoteness, make sure to activate the remote browser if needed. r=qdot

Not quite sure what's a good way to add a test for this... Ideas?

Comment 11

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Not real sure about how we're gonna run tests on this, especially since it already managed to land once with everything passing.

As for the browser not running destroy: I haven't seen any residuals from page changes so far using this patch, but I'm also not familiar with layout at all, so not quite sure what to be expecting.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d6564ee9d941
When a focused browser changes remoteness, make sure to activate the remote browser if needed. r=qdot

Comment 13

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/d6564ee9d941