Ticket #6825 (closed defect: invalid)

Opened 6 years ago

Last modified 23 months ago

Problems with email webfrontend www.adinet.com.uy

Reported by: epastorino Owned by: erikos
Priority: blocker Milestone: 8.2.0 (was Update.2)
Component: browse-activity Version: Development build as of this date
Keywords: Browse-94:+ joyride-2204:+ Cc: erikos, mstone, Eben, tomeu, kim, simon
Action Needed: qa signoff Verified: no
Deployments affected: Blocked By:
Blocking: #7421

Description

We've found a bug here in Uruguay in Browse activity. Kids can't upload images to their blogs at www.blogger.com or send mails using their accounts at www.adinet.com.uy. Both sites (and plenty more) use javascript for its user interface, but last versions of Web activity won't show some buttons on those sites. This worked on build 385, now we're testing build 703 with Browse activity version 86, but we've seen this behaviour since build 642 at least.

Attachments

upload-image.html (12.7 kB) - added by erikos 6 years ago.
page to upload the image
hulahop.patch (1.3 kB) - added by marco 6 years ago.
web1.patch (1.9 kB) - added by marco 6 years ago.
hulahop.2.patch (1.3 kB) - added by marco 6 years ago.
popup_browse.patch (2.2 kB) - added by marco 6 years ago.
popup_hulahop.patch (1.3 kB) - added by marco 6 years ago.
popup_browse_added_title.patch (2.4 kB) - added by erikos 6 years ago.
added title for popup

Change History

  Changed 6 years ago by epastorino

  • owner changed from erikos to epastorino

  Changed 6 years ago by mstone

  • cc erikos, mstone added

Simon - when might you be able to look into this?

  Changed 6 years ago by erikos

www.blogger.com:

  • The issue seems that our browser does not provide a done button when uploading an image which it does using another browser.
  • I verified that it has nothing to do with rainbow by switching it off.
  • The browse logs does not show anything special.
  • I checked with a firefox cvs version close to ours and can upload the image fine.
  • Since the upload dialog opens a new window this might be a hint what is causing the issue.

Attached is the browse log and the html site for the uploading of the image.

Changed 6 years ago by erikos

page to upload the image

  Changed 6 years ago by erikos

Could not upload the log because of 'too many external links'.

207564577.786699 DEBUG root: OnHistoryNewEntry: http://www.blogger.com/upload-image.g?blogID=4018404564047103150
1207564577.789355 DEBUG web-activity: NewPage: http://www.blogger.com/upload-image.g?blogID=4018404564047103150.
1207564577.879439 DEBUG root: nsIEmbeddingSiteWindow.set_title: u'Blogger: Upload Images'
1207564577.882153 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564577.885466 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564577.888584 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564577.890538 DEBUG web-activity: Title changed=Blogger: Upload Images
1207564577.894883 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564580.874969 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564580.881695 DEBUG root: nsIEmbeddingSiteWindow.setFocus
DEBUG:xpcom:Python Factory creating FilePicker
1207564588.191653 DEBUG xpcom: Python Factory creating FilePicker
1207564588.206214 WARNING root: FilePicker.appendFilters: UNIMPLEMENTED
1207564588.208515 WARNING root: Invocation of ObjectChooser() has deprecated parameters.
1207564594.734245 DEBUG root: ObjectChooser.__chooser_response_cb: dbus.String(u'3d431a42-50ad-45eb-a89b-443c4b8754d1')
1207564594.736680 DEBUG root: datastore.get
1207564594.738481 DEBUG root: dbus_helpers.get_properties: 3d431a42-50ad-45eb-a89b-443c4b8754d1
1207564594.793206 WARNING root: DSObject was deleted without cleaning up first. Please call DSObject.destroy() before disposing it.
1207564594.795413 DEBUG root: FilePicker.show: <sugar.datastore.datastore.DSObject object at 0x83daf4c>
1207564594.797247 DEBUG root: datastore.get
1207564594.799081 DEBUG root: dbus_helpers.get_properties: 3d431a42-50ad-45eb-a89b-443c4b8754d1
1207564594.840061 DEBUG root: dbus_helpers.get_filename: 3d431a42-50ad-45eb-a89b-443c4b8754d1, /home/olpc/isolation/1/uid_to_instance_dir/10001/3d431a42-50ad-45eb-a89b-443c4b8754d1.png
1207564594.850255 WARNING root: DSObject was deleted without cleaning up first. Please call DSObject.destroy() before disposing it.
1207564594.853299 DEBUG root: FilePicker.get_file: u'/home/olpc/isolation/1/uid_to_home_dir/10001/tmp/tmpmRlEXS.png'
1207564594.916185 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564594.924018 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564594.929831 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564594.932707 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564594.939602 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564594.959689 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564594.966681 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564594.972926 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564594.975708 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564594.982323 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564603.857764 DEBUG root: OnHistoryNewEntry: http://www.blogger.com/upload-image.do
1207564603.860269 DEBUG web-activity: NewPage: http://www.blogger.com/upload-image.do.
1207564603.923063 DEBUG root: filepicker.cleanup_temp_files: u'/home/olpc/isolation/1/uid_to_home_dir/10001/tmp/tmpmRlEXS.png'
1207564603.961873 DEBUG root: nsIEmbeddingSiteWindow.set_title: u'Blogger: Upload Images'
1207564603.964576 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564603.967766 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564603.970860 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564603.972807 DEBUG web-activity: Title changed=Blogger: Upload Images
1207564603.975260 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564607.816370 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564607.823235 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564747.148417 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564747.155204 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564747.161036 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564747.163957 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564747.170505 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564750.544722 DEBUG root: ActivityService.set_active: 0.
1207564750.546939 DEBUG root: Activity.save: dbus.String(u'082e2caf-9e67-48df-a396-2dcb09b2ef58')
1207564751.193736 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564751.196511 DEBUG root: nsIEmbeddingSiteWindow.get_title: u'Blogger: Upload Images'
1207564751.202978 DEBUG root: 7
1207564751.228808 DEBUG root: datastore.write
1207564751.231548 DEBUG root: dbus_helpers.update: 082e2caf-9e67-48df-a396-2dcb09b2ef58, /home/olpc/isolation/1/uid_to_home_dir/10001/instance/1207564751, {'activity_id': 'b35d80f0491ea6c4ba3b9b51951f9f10e1f678c3', 'title_set_by_user': '0', 'title': 'Blogger: Upload Images', 'timestamp': 1207564751, 'activity': 'org.laptop.WebActivity', 'share-scope': 'private', 'keep': '0', 'icon-color': '#B20008,#AC32FF', 'mtime': '2008-04-07T10:39:11.230374', 'preview': '<omitted>', 'mime_type': 'text/plain'}, True
1207564751.282128 DEBUG root: Written object 082e2caf-9e67-48df-a396-2dcb09b2ef58 to the datastore.
1207564751.379939 DEBUG root: Activity.__save_cb
1207564752.210400 DEBUG root: Activity.save: dbus.String(u'082e2caf-9e67-48df-a396-2dcb09b2ef58')
1207564752.216850 DEBUG root: 7
1207564752.242981 DEBUG root: datastore.write
1207564752.245529 DEBUG root: dbus_helpers.update: 082e2caf-9e67-48df-a396-2dcb09b2ef58, /home/olpc/isolation/1/uid_to_home_dir/10001/instance/1207564752, {'activity_id': 'b35d80f0491ea6c4ba3b9b51951f9f10e1f678c3', 'title_set_by_user': '1', 'title': 'Blogger: Upload Images', 'timestamp': 1207564752, 'activity': 'org.laptop.WebActivity', 'share-scope': 'private', 'keep': '0', 'icon-color': '#B20008,#AC32FF', 'mtime': '2008-04-07T10:39:12.244524', 'preview': '<omitted>', 'mime_type': 'text/plain'}, True
1207564752.251436 DEBUG root: Written object 082e2caf-9e67-48df-a396-2dcb09b2ef58 to the datastore.
1207564752.650164 DEBUG root: Activity.__save_cb
1207564794.580384 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564794.601050 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564794.613826 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564794.616615 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564794.623207 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564795.749087 DEBUG root: ActivityService.set_active: 1.
1207564801.685300 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564801.692122 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564801.698052 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564801.700842 DEBUG root: nsIEmbeddingSiteWindow.set_visibility: True
1207564801.707424 DEBUG root: nsIEmbeddingSiteWindow.setFocus
1207564803.244500 DEBUG root: OnHistoryNewEntry: http://www.google.de/
1207564803.247613 DEBUG web-activity: NewPage: http://www.google.de/.
1207564803.291292 DEBUG root: filepicker.cleanup_temp_files: u'/home/olpc/isolation/1/uid_to_home_dir/10001/tmp/tmpmRlEXS.png'
---------------------------------------------------------------------------
<type 'exceptions.OSError'>               Traceback (most recent call last)

/home/olpc/Activities/Web.activity/webtoolbar.py in _location_changed_cb(self=<WebToolbar object at 0x83c6414 (WebToolbar at 0x897e000)>, progress_listener=<ProgressListener object at 0x8698edc (progresslistener+ProgressListener at 0x8864d70)>, uri=<XPCOM component '<unknown>' (implementing nsIURI)>)
    108         self._set_address(ui_uri)
    109         self._update_navigation_buttons()
--> 110         filepicker.cleanup_temp_files()
        global filepicker.cleanup_temp_files = <function cleanup_temp_files at 0x84c85a4>
    111 
    112     def _loading_start_cb(self, progress_listener):

/home/olpc/Activities/Web.activity/filepicker.py in cleanup_temp_files()
     34     for temp_file in _temp_files_to_clean:
     35         logging.debug('filepicker.cleanup_temp_files: %r' % temp_file)
---> 36         os.remove(temp_file)
        global os.remove = <built-in function remove>
        temp_file = u'/home/olpc/isolation/1/uid_to_home_dir/10001/tmp/tmpmRlEXS.png'
     37 
     38 class FilePicker:

<type 'exceptions.OSError'>: [Errno 2] No such file or directory: '/home/olpc/isolation/1/uid_to_home_dir/10001/tmp/tmpmRlEXS.png'

  Changed 6 years ago by holt

  Changed 6 years ago by erikos

  • milestone changed from Update.1 to Retriage, Please!

I updated to xulrunner beta5 but the behavior is the same for blogger.com. You cannot upload an image.

Can you describe in more detail what you see on www.adinet.com.uy ? Does this try to open a new window maybe?

follow-up: ↓ 9   Changed 6 years ago by epastorino

Yes, when you want to send a new mail, it opens a new window, but that never happens and the xo hangs (in build 642). In last build (703), Browse version 86, it opens the window but this message pops-up: "A script on this page may be busy, or it may have stopped responding. You can stop the script now or you can continue to see if the script will complete." If you stop the script, you can write your message and send it, but when you do so, the page stays blank instead of showing a "Message sent" and returning to inbox.

  Changed 6 years ago by erikos

  • owner changed from epastorino to erikos
  • summary changed from JavaScript not fully supported in Browse activity to Problems with email webfrontend www.adinet.com.uy

Let's make this bug about the email webfrontend. #6826 tracks the issue with uploading images to blogger.com

in reply to: ↑ 7   Changed 6 years ago by tomeu

  • cc Eben, tomeu added

Replying to epastorino:

Yes, when you want to send a new mail, it opens a new window, but that never happens and the xo hangs (in build 642). In last build (703), Browse version 86, it opens the window but this message pops-up: "A script on this page may be busy, or it may have stopped responding. You can stop the script now or you can continue to see if the script will complete." If you stop the script, you can write your message and send it, but when you do so, the page stays blank instead of showing a "Message sent" and returning to inbox.

Eben, AFAICS, this is derived by our decision to open popups on the existing window. What could we do in these cases?

Thanks

  Changed 6 years ago by Eben

Unfortunately, this is a really hard problem for us. Does anyone know how web kiosks handle this? Looking around online, I found several references which state that they just don't at all, which is discouraging.

Opening a new window in fullscreen isn't an attractive solution. We tried this before and it led to a very confusing user experience, in large part because the fullscreen nature of the window prevented the user from understanding that it was a new instance. The page nav stack got lost, and when the window was closed, the user wouldn't necessarily end up back in the previous instance. It was quite disorienting. It also goes against the session model, creating a separate instance, with separate sharing scope, and a separate Journal entry, counter to the goals of the Sugar activity model. For that matter, does this even support the use case of parent/child window communication? Under Rainbow, it shouldn't by definition.

The next option we tried, and what I believe we do now, is simply ignore the request for a blank window and open the link within the current browse instance, simply adding it to the navigation stack like any other link. This has decent behavior someof the time, but obviously breaks when the site places dependency on child windows, requiring interaction between them and the parent. I assume this is what gets us in trouble in both of the instances mentioned in this ticket.

An option I would approve of (but which I admit might not even be possible...) would be to create a pseudo-window of some kind, which behaves in most ways like a popup window, but without actually being one. As a for instance, consider creating a DIV containing and IFRAME at the top level of the document, specifying a target for the iframe based on the name specified in the link, and subsequently aliasing this in some fashion such that any javascript references or link targets wind up referring to the IFRAME instead. Special support could be added to this "wrapper" DIV to support drag'n'drop, resizing, etc. The intended goal here is to provide a popup-like experience with a floating child window, without breaking from the single-window fullscreen model in actuality.

Another option which relates closely to the above would be to achieve a similar, though slightly less elegant effect, by using frames split the page in two, keeping the parent on top and revealing the child window below. I don't really like this solution much.

Finally, if we decide to add true tab support, we might be able to get away with simply opening the popup in a new tab. This has a few user experience problems akin to the first solution mentioned above, but at least it doesn't break the activity instance model, and it isn't quite as contradictory to the navigation stack, since the new tab will show up in context, and the parent page remains visibly accessible. Unfortunately, even this might not always solve the problem. I know Gmail does some magic which forces a popup for me in Safari, even when I explicitly hold down the command key to request that Safari open the link in a new tab...

Obviously I'm nowhere close to solving this problem on my own. It's a tricky one. Thoughts on the pros/cons/feasibility of the above proposals are welcome.

  Changed 6 years ago by walter

While I agree that a tab solution is perhaps the best option of the ones you've brought up, but I would argue that violating the instance model is better than having the failures being experienced in Uruguay and elsewhere. You can learn to accommodate the confusion of the new window being created, but you cannot accommodate when the interaction fails. Can we go back to the "unattractive" but works solution of opening a window until we have a better solution in hand?

  Changed 6 years ago by Eben

If it actually does solve more problems than it causes, it might be worth reinstating. However, as I mentioned, I'm unsure that this would even solve the one "valid" use case for spawning child windows, which is communication between parent and child. We'll need technical feedback on that.

  Changed 6 years ago by gregorio

  • keywords blocks:8.2.0, added
  • next_action set to never set

Hi Guys,

This is a serious problem for Uruguay. I'm requesting it be resolved ASAP, target 8.2.0.

I believe the same problem is tracked under: http://dev.laptop.org/ticket/6826

Thanks,

Greg S

  Changed 6 years ago by gregorio

  • milestone changed from Retriage, Please! to 8.2.0 (was Update.2)

  Changed 6 years ago by mstone

We know that Firefox runs quite nicely on the XO. It's even available as an activity -- see http://wiki.laptop.org/go/Activities. Since the design process seems to be stuck on this ticket, perhaps we could work around the problem by recommending to UY that they test FF.xo and include it in their release if it works for them?

  Changed 6 years ago by mstone

  • keywords 8.2.0:? added; javascript browse activity bug removed
  • owner changed from erikos to gregorio
  • next_action changed from never set to communicate

  Changed 6 years ago by gregorio

  • cc kim, simon added

Hi Michael,

I don't think we can ask them to use FF. I know there has been some debate about browsers recently (although I didn't read the whole thread) but either we support our browser and make it work or we don't. Its a central tool and I think we have to support it for all critical deployments until we make a decision to do something else.

In short, that may be a viable idea eventually but the plan of record is that we support Browse. BTW this is a regression. This used to work (they posted lots of great picture for a while) then it stopped working in later builds.

BTW can you help me get this assigned to the right person (is it a sugar developer?). If its in the sugar camp, can you tell me how I ensure they make it a priority?

BTW I worked on this bug as a volunteer and I have some more background on it if anyone needs it.

Thanks,

Greg S

  Changed 6 years ago by gregorio

  • owner changed from gregorio to erikos

follow-up: ↓ 20   Changed 6 years ago by erikos

please see #6826 for a first patch

in reply to: ↑ 19   Changed 6 years ago by epastorino

Replying to erikos:

please see #6826 for a first patch

Just tried the patch with www.adinet.com.uy Now we can send mails, but we can't attach files to them. The objectchoser works fine, we can select images to be attached, but when we click on "Attach files" button, the progress bar starts to load, but it gets stucked nearly by the end.

Also, when you click on the "Send mail" button, the mail is sent, but the popup should close and a new popup with a "Mail sent" message should open. Instead of that, it seems that the content of the popup is cleaned, but the window won't close. You have to close it with the window's close button, so this isn't critical.

follow-up: ↓ 22   Changed 6 years ago by cscott

  • blocking 7413 added

Suggested workaround for 8.2: install Firefox activity (http://wiki.laptop.org/go/Activities).

in reply to: ↑ 21   Changed 6 years ago by marco

Replying to cscott:

Suggested workaround for 8.2: install Firefox activity (http://wiki.laptop.org/go/Activities).

No. The Browse bug is currently a 8.2.0 blocker and hence have to be fixed.

  Changed 6 years ago by gregorio

Hi All,

When I expressed concerns with using Firefox, I meant that we should not ask that users install a different browser. If you meant "use firefox as the base of the source for our browse activity" then I'm fine with that. As long as it does everything we currently do and fixes this problem.

I got this description from how Birmingham installed Firefox and I don't want to ask every kid or teacher in Uruguay to do this.

Thanks,

Greg S

Here's how I installed and sugarized Firefox:

Firefox Installation

First, allow Firefox to be installed:

cd /etc/yum.repos.d

nano olpc-koji-ship2.repo

uncomment the line excluding firefox

Ctrl+ X, then write out

yum install firefox

run firefox as olpc to generate config files

"Sugarize" Firefox

http://www.catmoran.com/olpc/#sugxterm

(icon from http://webcvs.freedesktop.org/svg-icons/lila/gnome/scalable/apps/firefox-icon.svg?revision=1.4)

Performance Tweaks for Firefox

http://portableapps.com/support/firefox_portable#performance

Enable mss streams in Firefox

Aptplus.org and other sites have mms streams of video content. Click to play in outside player and mplayer will automatically open (given that mplayer is installed, of course)

about:config

Right click > New > String

network.protocol-handler.app.mms

/usr/bin/mplayer

Right click > New > Boolean

network.protocol-handler.external.mms

True

  Changed 6 years ago by cscott

Installation of Firefox is as easy as going to http://wiki.laptop.org/go/Activities and clicking on the Firefox.xo found there.

This may or may not be a blocker; all I'm pointing out is that there is a workaround which may or may not be sufficient to get us past 8.2. I did not change the status of this bug wrt to the release, that's not my job.

  Changed 6 years ago by erikos

@epastorino: I can reproduce the upload problem for images as attachments. This looks tricky, it does work with other image upload interfaces i have tried wiki.laptop.org for example or other email webfrontends (e.g. web.de). Don't know yet what is causing this. Probably some communication that is going back and forth between the windows (to upload an attachment there are two open).

  Changed 6 years ago by marco

  • priority changed from high to blocker
  • next_action changed from communicate to diagnose

  Changed 6 years ago by erikos

Open issues:

- the JS close is not handled by the gtk window (should be handled by http://www.xulplanet.com/references/xpcomref/ifaces/nsIWebBrowserChrome.html#method_destroyBrowserWindow)

- the uploading of images as an attachment does not work (the progress bar never completes and the file does not get uploaded)

- we need to handle cases like target='_blank' and target='blah' - those should be handled in the parent window and not in the popup (not sure how to differentiate best in the providewindow handler http://www.xulplanet.com/references/xpcomref/ifaces/nsIWindowProvider.html)

  Changed 6 years ago by walter

- we need to handle cases like target='_blank' and target='blah'

We used to just launch a separate browser instance for target='_blank'. While not ideal--it wasn't obvious a new browse was launched--it worked and may be the most expedient course for 8,2.

  Changed 6 years ago by Eben

We used to open them in place in the same window, too. The point here is that we need to place JS spawned windows in a popup so they remain in context with the parent and can be referenced in code; the other cases should be handled separately. The trick is differentiating them in the first place, in which case we can certainly continue to use the single-instance trick.

  Changed 6 years ago by cscott

  • blocking 7421 added; 7413 removed

Changed 6 years ago by marco

Changed 6 years ago by marco

  Changed 6 years ago by marco

These two patches fixes all the issues afaict. Unsized/unpositioned popups are opened in the same window, the others as dialogs transient to the activity window.

  Changed 6 years ago by marco

  • keywords r? added

  Changed 6 years ago by Eben

This should be a pretty reliable solution in nearly all cases. Unfortunately, we can't reliably tell the difference between windows invoked with the JS window.open method and those created with a targeted link. The two things we know are

  1. The title of the window, either passed as a required argument to window.open, or specified as the target parameter on an <a> tag.
  2. A features string - containing size, position, chrome, and other window properties - passed as an optional parameter to window.open.

The first of these allows us to detect when a special target (_blank, _top, etc.) is passed, in which case we assume that the window was opened from an <a> tag (and can be safely opened in place, since there is no JS communication between child/parent.). However, we can't tell the difference between a named target and a window.open call.

So the choice to make is whether we show anything window with a custom name in a popup (which is overly eager), or make the assumption that any window.open call that intends to facilitate further communication will include a features specification (which could miss some cases which depend on that communication). This patch, and the opinion on Marco and I at present, is that the likelihood of these edge cases we could miss is extremely small, and so we take the risk.

However, if it turns out that real-life experiences illustrate that is not the case, it should be a trivial task to err in the other direction.

follow-up: ↓ 35   Changed 6 years ago by walter

This patch, and the opinion on Marco and I at present, is that the likelihood of these edge cases we could miss is extremely small, and so we take the risk.

Do any of these edge cases include the websites important to Uruguay?

in reply to: ↑ 34   Changed 6 years ago by marco

Replying to walter:

Do any of these edge cases include the websites important to Uruguay?

Not that we know of.

  Changed 6 years ago by marco

I found a couple of reassuring things about the logic we are considering to adopt:

1 Firefox uses the same logic to decide if a page should be opened in a new tab or in a new window, by default. 2 Firefox seem to have moved from the target vs window.open logic, to checking size/features.

Obviously if firefox get it wrong, the problem is much minor (the page will just be hidden in a tab), but still I think it mitigates our risk quite a bit.

Changed 6 years ago by marco

follow-up: ↓ 38   Changed 6 years ago by marco

  • keywords r? removed
  • next_action changed from diagnose to communicate

web1 and hulahop2 implements the logic Eben discussed. I already found a problem with it though, clicking on a link in gmail breaks.

We need another plan, I guess.

in reply to: ↑ 37   Changed 6 years ago by tomeu

Replying to marco:

web1 and hulahop2 implements the logic Eben discussed. I already found a problem with it though, clicking on a link in gmail breaks.

Note that for those cases, you can work around it by using the palette for links.

  Changed 6 years ago by marco

Tomeu, yeah... But even just gmail alone seems too important to rely on work arounds :/

  Changed 6 years ago by marco

This bug has an *old* patch which implemented the behavior Eben would like.

https://bugzilla.mozilla.org/show_bug.cgi?id=56296

We would have to update it to work with the latest go and to try to get it upstream, if we wanted to go down this way.

  Changed 6 years ago by marco

  • keywords r? added

This *might* be the best I can provide without adding tab support.

target="_blank" is opened in the same window, the rest is opened in a transient dialog with no navigation toolbar. It won't break any website, but the lack of navigation toolbar on some pages will likely annoy users (workaround is to "follow link" from the link palette).

I'd start to get this reviewed and landed since it improves the code and add support for stuff we will need in any case. Than we can discuss if it's enough for 8.2 or if there are improvements we can make.

Changed 6 years ago by marco

Changed 6 years ago by marco

Changed 6 years ago by erikos

added title for popup

  Changed 6 years ago by erikos

  • keywords r+ added; r? removed
  • next_action changed from communicate to review

could not verify adinet (since the site seems to be down), but the rest looks really good and works well.

  Changed 6 years ago by marco

  • next_action changed from review to package

  Changed 6 years ago by erikos

Bundled in http://dev.laptop.org/~erikos/bundles/Browse-94.xo

And hulahop 0.4.2-1 went into joyride-2204

  Changed 6 years ago by marco

  • keywords joyride-2220:- added

Simon forgot to push this in joyride.

  Changed 6 years ago by erikos

  • keywords Browse-94:+ joyride-2204:+ added; blocks:8.2.0, 8.2.0:? r+ joyride-2220:- removed
  • next_action changed from package to qa signoff

|TestCase|

Send an email using the adinet.com.uy site. Make sure to test as well that attaching a document (photo) does work.

  Changed 23 months ago by godiard

  • status changed from new to closed
  • resolution set to invalid

4 years without reply. Can't reproduce.

Tested send a mail in gmail attaching a image, with Browse 140

Note: See TracTickets for help on using tickets.