loaded page breaks after using (xpi + browser.link.open_external:1) - context menus, reload, forms all broken.

NEW
Unassigned

Status

()

13 years ago
9 years ago

People

(Reporter: maxxmozilla, Unassigned)

Tracking

({regression})

Trunk
x86
Windows 2000
regression
Points:
---
Bug Flags:
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050930 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050930 Firefox/1.6a1

Bug 300114 (fixed by bug 271567) is not anymore but after accepting/rejecting
xpinstall dialog, page in active tab is not fully usable (probably caused by Bug
298255 and IIRC this wasn't the case in FF 1.0.4).
Details below.

Reproducible: Always

Steps to Reproduce:
1. Load any page, e.g. http://www.extensionsmirror.nl/ ;)
2. Double click on local xpi (accept/reject xpinstall dialog)
with setting (browser.link.open_external:1) = Tools -> Options... -> Tabs -
'Open links from
other applications in:' - 'the most recent tab/window'
3. Check if loaded page if fully usable as it was before

Actual Results:  
The page is not fully usable, you can't: use context menu, refresh the page,
type in edit boxes etc.

Expected Results:  
a) The page is fully usable (preferred)
b) blank currently loaded page before showing xpinstall dialog so user could go
back to fully working page (do not blank if the current page is about:blank)
(Reporter)

Updated

13 years ago
Keywords: regression
(Reporter)

Updated

13 years ago
Flags: blocking1.8b5?

Comment 1

13 years ago
Dan, can you dig into this?
Assignee: xpi-engine → dveditz
Flags: blocking1.8b5? → blocking1.8b5+

Updated

13 years ago
Summary: loaded page becomes partially usable (xpi + browser.link.open_external:1) → loaded page breaks after using (xpi + browser.link.open_external:1) - context menus, reload, forms all broken.
This is not unique to xpinstall, this happens for any type not handled by
layout. Mostly those types are externally handled, so if you double-clicked in
the OS you'd never go through Firefox in the first place (on the other hand,
xpinstall doesn't go to Firefox by default either). But if you force the issue
by passing the file on the commandline, then you get the same result.

Example: Assume you have pdf's set to open in the external reader (not the
plugin). firefox "file:///c:/path/myfile.pdf" will switch the current tab title
to "Untitled", then pass the PDF to the external handler. The existing content
will be broken in the same way as this bug describes for xpinstall.

Confirming bug. I don't see it as a blocker:
- replace current content is not the default behavior
- it's not a new problem (though masked for .xpi until recently)
- only a minority have local .xpi to click on
- by default .xpi doesn't open in Firefox anyway

The most annoying thing is that the original page was not entered into session
history when we started loading the new content, so you can't "go back" to it.
But apparently we started enough on the new page that you can't "reload" it either.
Status: UNCONFIRMED → NEW
Component: Installer: XPInstall Engine → Embedding: Docshell
Ever confirmed: true
Flags: blocking1.8b5+ → blocking1.8b5?

Updated

13 years ago
Flags: blocking1.8b5? → blocking1.8b5-
Oh, and the 1.0x branch doesn't have this problem, so it's something that
regressed at some point on the trunk.
(Reporter)

Comment 4

13 years ago
(In reply to comment #2)
> - replace current content is not the default behavior
yeah now it isn't but wouldn't the majority of users reuse their 1.0.x profiles ?

> - by default .xpi doesn't open in Firefox anyway
hmm maybe I did it long time ago myself but like firefox associates itself with
.html etc. extensions it should do the same with .xpi (especially that this file
extension is rather only used by mozilla browsers) ?
Anyway I can agree that this bug affects a minority of firefox users.

(In reply to comment #3)
> Oh, and the 1.0x branch doesn't have this problem, so it's something that
> regressed at some point on the trunk.
huh ? I've noticed this behaviour when reporting Bug 300114 but I didn't said
anything about it because I had thought that patch to this bug would fix also
'page breaking'.
Note that on 1.0.5+ all what I've said in this bug applies beside that you can
reload the page but you can't scroll the page.
Nightly trunk behaviour matches nightly branch behaviour.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915
Firefox/1.0.7
So the issue here is the CreateAboutBlankContentViewer() call that we make in the aLoadType == LOAD_NORMAL_EXTERNAL call, right?

So what behavior do we want here?  Given how the JS protocol handler works, we have to clear before AsyncOpen.  But we won't know where we're targeting (or whether we can handle) until after AsyncOpen...

Perhaps we should simply remove support for the "current window" value of this pref?  I see no way to implement it safely and without breaking things like this.
Blocks: 298255
The behaviour I'd want is for -url to run the URL through the doc loader and only if it generated HTML¹ content would it look for a docshell to load in.

¹Or other supported MIME types, of course.
> run the URL through the doc loader

That requires having a docshell at the moment (if nothing else, "javascript:" URIs need a script context to run against).
Assignee: dveditz → nobody
QA Contact: docshell
You need to log in before you can comment on or make changes to this bug.